summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-12-15Merge tag 'riscv/for-v5.5-rc2' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Two minor build fixes: - Fix builds of the ELF loader when built with 'make -j1' (nommu only) - Fix CONFIG_SOC_SIFIVE builds when CONFIG_TTY is disabled (found during randconfig testing)" * tag 'riscv/for-v5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: only select serial sifive if TTY is enabled riscv: Fix build dependency for loader
2019-12-15parisc: add missing __init annotationSven Schnelle1-1/+1
compilation failed with: MODPOST vmlinux.o WARNING: vmlinux.o(.text.unlikely+0xa0c): Section mismatch in reference from the function walk_lower_bus() to the function .init.text:walk_native_bus() The function walk_lower_bus() references the function __init walk_native_bus(). This is often because walk_lower_bus lacks a __init annotation or the annotation of walk_native_bus is wrong. FATAL: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[2]: *** [/home/svens/linux/parisc-linux/src/scripts/Makefile.modpost:64: __modpost] Error 1 make[1]: *** [/home/svens/linux/parisc-linux/src/Makefile:1077: vmlinux] Error 2 make[1]: Leaving directory '/home/svens/linux/parisc-linux/build' make: *** [Makefile:179: sub-make] Error 2 Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Helge Deller <deller@gmx.de>
2019-12-15parisc: fix compilation when KEXEC=n and KEXEC_FILE=ySven Schnelle2-5/+1
Fix compilation when the CONFIG_KEXEC_FILE=y and CONFIG_KEXEC=n. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Helge Deller <deller@gmx.de>
2019-12-14Merge tag 'Wimplicit-fallthrough-5.5-rc2' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull fall through fix from Gustavo Silva: "Fix compile error on sh by marking expected switch fall-through" * tag 'Wimplicit-fallthrough-5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: sh: kgdb: Mark expected switch fall-throughs
2019-12-14Merge tag 'driver-core-5.5-rc2' of ↵Linus Torvalds1-9/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fixes from Greg KH: "Here are two small driver core fixes to resolve some reported issues The first is to handle the much-reported (by the build systems) problem that superH does not boot anymore. The second handles an issue in the new platform logic that a number of people ran into with the automated tests in kbuild Both of these have been in linux-next with no reported issues" * tag 'driver-core-5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: drivers: Fix boot problem on SuperH of/platform: Unconditionally pause/resume sync state during kernel init
2019-12-14Merge tag 's390-5.5-3' of ↵Linus Torvalds9-47/+80
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 updates from Vasily Gorbik: - Add support for KASAN_VMALLOC feature. - Remove the last user of problematic diag 0x44 call. - Adjust sampling interval and avoid sample data block overflow condition on pressure in perf code. - Prefer EOPNOTSUPP over ENOTSUPP and comments fixes. * tag 's390-5.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/kasan: add KASAN_VMALLOC support s390: remove last diag 0x44 caller s390/uv: use EOPNOTSUPP instead of ENOTSUPP s390/cpum_sf: Avoid SBD overflow condition in irq handler s390/cpum_sf: Adjust sampling interval to avoid hitting sample limits s390/test_unwind: fix spelling mistake "reqister" -> "register" s390/spinlock: remove confusing comment in arch_spin_lock_wait
2019-12-14Merge branch 'linus' of ↵Linus Torvalds1-0/+7
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix another build problem for Wireguard without Crypto" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: arm/curve25519 - add arch-specific key generation function
2019-12-14x86/boot: kbuild: allow readelf executable to be specifiedDmitry Golovin1-1/+1
Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: https://github.com/ClangBuiltLinux/linux/issues/771 Signed-off-by: Dmitry Golovin <dima@golovin.in> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-12-13Merge tag 'nios2-v5.5-rc2' of ↵Linus Torvalds1-0/+8
git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2 Pull nios2 fix from Ley Foon Tan: "Fix nios2 ioremap regression" * tag 'nios2-v5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/lftan/nios2: nios2: Fix ioremap
2019-12-13Merge tag 'sizeof_field-v5.5-rc2' of ↵Linus Torvalds6-26/+19
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull FIELD_SIZEOF conversion from Kees Cook: "A mostly mechanical treewide conversion from FIELD_SIZEOF() to sizeof_field(). This avoids the redundancy of having 2 macros (actually 3) doing the same thing, and consolidates on sizeof_field(). While "field" is not an accurate name, it is the common name used in the kernel, and doesn't result in any unintended innuendo. As there are still users of FIELD_SIZEOF() in -next, I will clean up those during this coming development cycle and send the final old macro removal patch at that time" * tag 'sizeof_field-v5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: Use sizeof_field() macro MIPS: OCTEON: Replace SIZEOF_FIELD() macro
2019-12-14powerpc/irq: fix stack overflow verificationChristophe Leroy1-2/+2
Before commit 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of the irq stack"), check_stack_overflow() was called by do_IRQ(), before switching to the irq stack. In that commit, do_IRQ() was renamed __do_irq(), and is now executing on the irq stack, so check_stack_overflow() has just become almost useless. Move check_stack_overflow() call in do_IRQ() to do the check while still on the current stack. Fixes: 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of the irq stack") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/e033aa8116ab12b7ca9a9c75189ad0741e3b9b5f.1575872340.git.christophe.leroy@c-s.fr
2019-12-13Merge tag 'omap-for-v5.5/fixes-rc1-signed' of ↵Olof Johansson4-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes Fixes for omap variants for v5.5-rc1 cycle This series of changes contains fixes for issues recently noticed: - The ti-sysc interconnect target module driver needs fixes for mstandby quirk handling and reset delay - We need to configure am335x-sancloud-bbe to use rgmii-id mode because of the phy changes done earlier - NET_SWITCHDEV is no longer selected in Kconfig but a dependency and we must enable CONFIG_NET_SWITCHDEV to have TI_CPSW_SWITCHDEV - We are still relying on DEBUG_FS at least for PM configuration, let's add it back - We need to update compatible for am437x-gp/epos-evm because of the recent changes to use generic panels * tag 'omap-for-v5.5/fixes-rc1-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: Fix missing reset delay handling ARM: dts: am437x-gp/epos-evm: fix panel compatible ARM: omap2plus_defconfig: Add back DEBUG_FS ARM: omap2plus_defconfig: enable NET_SWITCHDEV ARM: dts: am335x-sancloud-bbe: fix phy mode bus: ti-sysc: Fix missing force mstandby quirk handling Link: https://lore.kernel.org/r/pull-1576254925-709310@atomide.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-13ARM: shmobile: defconfig: Restore debugfs supportGeert Uytterhoeven1-0/+1
Since commit 0e4a459f56c32d3e ("tracing: Remove unnecessary DEBUG_FS dependency"), CONFIG_DEBUG_FS is no longer auto-enabled. This breaks booting Debian 9, as systemd needs debugfs: [FAILED] Failed to mount /sys/kernel/debug. See 'systemctl status sys-kernel-debug.mount' for details. [DEPEND] Dependency failed for Local File Systems. ... You are in emergGive root password for maintenance (or press Control-D to continue): Fix this by enabling CONFIG_DEBUG_FS explicitly. See also commit 18977008f44c66bd ("ARM: multi_v7_defconfig: Restore debugfs support"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20191209101327.26571-1-geert+renesas@glider.be
2019-12-13powerpc: Ensure that swiotlb buffer is allocated from low memoryMike Rapoport1-0/+8
Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a system has more physical memory than this limit, the swiotlb buffer is not addressable because it is allocated from memblock using top-down mode. Force memblock to bottom-up mode before calling swiotlb_init() to ensure that the swiotlb buffer is DMA-able. Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191204123524.22919-1-rppt@kernel.org
2019-12-13powerpc/shared: Use static key to detect shared processorSrikar Dronamraju1-7/+2
With the static key shared processor available, is_shared_processor() can return without having to query the lppaca structure. Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by: Phil Auld <pauld@redhat.com> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191213035036.6913-2-mpe@ellerman.id.au
2019-12-13powerpc/vcpu: Assume dedicated processors as non-preemptSrikar Dronamraju2-1/+10
With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs"), the scheduler avoids preempted vCPUs to schedule tasks on wakeup. This leads to wrong choice of CPU, which in-turn leads to larger wakeup latencies. Eventually, it leads to performance regression in latency sensitive benchmarks like soltp, schbench etc. On Powerpc, vcpu_is_preempted() only looks at yield_count. If the yield_count is odd, the vCPU is assumed to be preempted. However yield_count is increased whenever the LPAR enters CEDE state (idle). So any CPU that has entered CEDE state is assumed to be preempted. Even if vCPU of dedicated LPAR is preempted/donated, it should have right of first-use since they are supposed to own the vCPU. On a Power9 System with 32 cores: # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-63 NUMA node1 CPU(s): 64-127 # perf stat -a -r 5 ./schbench v5.4 v5.4 + patch Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 45 75.0000th: 62 75.0th: 63 90.0000th: 71 90.0th: 74 95.0000th: 77 95.0th: 78 *99.0000th: 91 *99.0th: 82 99.5000th: 707 99.5th: 83 99.9000th: 6920 99.9th: 86 min=0, max=10048 min=0, max=96 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 72 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 691 *99.0th: 83 99.5000th: 3972 99.5th: 85 99.9000th: 8368 99.9th: 91 min=0, max=16606 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 71 90.0th: 75 95.0000th: 77 95.0th: 79 *99.0000th: 106 *99.0th: 83 99.5000th: 2364 99.5th: 84 99.9000th: 7480 99.9th: 90 min=0, max=10001 min=0, max=95 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 47 75.0000th: 62 75.0th: 65 90.0000th: 72 90.0th: 75 95.0000th: 78 95.0th: 79 *99.0000th: 93 *99.0th: 84 99.5000th: 108 99.5th: 85 99.9000th: 6792 99.9th: 90 min=0, max=17681 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 46 50.0th: 45 75.0000th: 62 75.0th: 64 90.0000th: 73 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 113 *99.0th: 82 99.5000th: 2724 99.5th: 83 99.9000th: 6184 99.9th: 93 min=0, max=9887 min=0, max=111 Performance counter stats for 'system wide' (5 runs): context-switches 43,373 ( +- 0.40% ) 44,597 ( +- 0.55% ) cpu-migrations 1,211 ( +- 5.04% ) 220 ( +- 6.23% ) page-faults 15,983 ( +- 5.21% ) 15,360 ( +- 3.38% ) Waiman Long suggested using static_keys. Fixes: 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs") Cc: stable@vger.kernel.org # v4.18+ Reported-by: Parth Shah <parth@linux.ibm.com> Reported-by: Ihor Pasichnyk <Ihor.Pasichnyk@ibm.com> Tested-by: Juri Lelli <juri.lelli@redhat.com> Acked-by: Waiman Long <longman@redhat.com> Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Acked-by: Phil Auld <pauld@redhat.com> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.ibm.com> Tested-by: Parth Shah <parth@linux.ibm.com> [mpe: Move the key and setting of the key to pseries/setup.c] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191213035036.6913-1-mpe@ellerman.id.au
2019-12-12Merge tag 'imx-fixes-5.5' of ↵Olof Johansson5-17/+35
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.5: - Add missing jedec,spi-nor compatible for imx6ul-14x14-evk board, so that SPI NOR device can be probed. - Fix power button of E60K02 board by removing LDORTC2 regulator. - A couple of fixes on serial number support of i.MX6ULL/ULZ SoCs to remove the boot regression caused by 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs"). - A couple of fixes on LS1028A SoC TMU regarding to calibration data and reboot register configuration. - Fix a regression seen on imx6ul-evk board by marking always-on for the regulator that is shared by many peripherals. - Explicitly restore CONFIG_DEBUG_FS in imx_v6_v7_defconfig. * tag 'imx-fixes-5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: imx: Fix boot crash if ocotp is not found ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS ARM: dts: imx6ul-evk: Fix peripheral regulator arm64: dts: ls1028a: fix reboot node arm64: dts: ls1028a: fix typo in TMU calibration data ARM: imx: Correct ocotp id for serial number support of i.MX6ULL/ULZ SoCs ARM: dts: e60k02: fix power button ARM: dts: imx6ul: imx6ul-14x14-evk.dtsi: Fix SPI NOR probing Link: https://lore.kernel.org/r/20191212122427.GK15858@dragon Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-12KVM: arm64: Ensure 'params' is initialised when looking up sys registerWill Deacon1-1/+4
Commit 4b927b94d5df ("KVM: arm/arm64: vgic: Introduce find_reg_by_id()") introduced 'find_reg_by_id()', which looks up a system register only if the 'id' index parameter identifies a valid system register. As part of the patch, existing callers of 'find_reg()' were ported over to the new interface, but this breaks 'index_to_sys_reg_desc()' in the case that the initial lookup in the vCPU target table fails because we will then call into 'find_reg()' for the system register table with an uninitialised 'param' as the key to the lookup. GCC 10 is bright enough to spot this (amongst a tonne of false positives, but hey!): | arch/arm64/kvm/sys_regs.c: In function ‘index_to_sys_reg_desc.part.0.isra’: | arch/arm64/kvm/sys_regs.c:983:33: warning: ‘params.Op2’ may be used uninitialized in this function [-Wmaybe-uninitialized] | 983 | (u32)(x)->CRn, (u32)(x)->CRm, (u32)(x)->Op2); | [...] Revert the hunk of 4b927b94d5df which breaks 'index_to_sys_reg_desc()' so that the old behaviour of checking the index upfront is restored. Fixes: 4b927b94d5df ("KVM: arm/arm64: vgic: Introduce find_reg_by_id()") Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191212094049.12437-1-will@kernel.org
2019-12-12nios2: Fix ioremapGuenter Roeck1-0/+8
Commit 5ace77e0b41a ("nios2: remove __ioremap") removed the following code, with the argument that cacheflag is always 0 and the expression would therefore always be false. if (IS_MAPPABLE_UNCACHEABLE(phys_addr) && IS_MAPPABLE_UNCACHEABLE(last_addr) && !(cacheflag & _PAGE_CACHED)) return (void __iomem *)(CONFIG_NIOS2_IO_REGION_BASE + phys_addr); This did not take the "!" in the expression into account. Result is that nios2 images no longer boot. Restoring the removed code fixes the problem. Fixes: 5ace77e0b41a ("nios2: remove __ioremap") Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
2019-12-12crypto: arm/curve25519 - add arch-specific key generation functionJason A. Donenfeld1-0/+7
Somehow this was forgotten when Zinc was being split into oddly shaped pieces, resulting in linker errors. The x86_64 glue has a specific key generation implementation, but the Arm one does not. However, it can still receive the NEON speedups by calling the ordinary DH function using the base point. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-12ARM: imx: Fix boot crash if ocotp is not foundLeonard Crestez1-1/+3
The imx_soc_device_init functions tries to fetch the ocotp regmap in order to soc serial number. If regmap fetch fails then a message is printed but regmap_read is called anyway and the system crashes. Failing to lookup ocotp regmap shouldn't be a fatal boot error so check that the pointer is valid. Only side-effect of ocotp lookup failure now is that serial number will be reported as all-zeros which is acceptable. Cc: stable@vger.kernel.org Fixes: 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-12ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FSLeonard Crestez1-0/+1
This is currently off and that's not desirable: default imx config is meant to be generally useful for development and debugging. Running git bisect between v5.4 and v5.5-rc1 finds this started from commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") Explicit CONFIG_DEBUG_FS=y was earlier removed by commit c29d541f590c ("ARM: imx_v6_v7_defconfig: Remove unneeded options") A very similar fix was required before: commit 7e9eb6268809 ("ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-12ARM: dts: imx6ul-evk: Fix peripheral regulatorLeonard Crestez1-6/+20
Many peripherals are affected by gpio5/2, not just sensors. One of those is ethernet phy so network boot is current broken. Fix by renaming reg_sensors and marking it as "always on". Also add a comment asking for careful testing if this is to be made dynamic in the future. The "peri_3v3" naming is similar to imx6sx-sdb and regulator-name is same string as in schematics (VPERI_3V3). Fixes: 09e2b1048954 ("ARM: dts: imx6ul-14x14-evk: Add sensors' GPIO regulator") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-12arm64: dts: ls1028a: fix reboot nodeMichael Walle1-1/+7
The reboot register isn't located inside the DCFG controller, but in its own RST controller. Fix it. Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-11Merge tag 'trace-v5.5-3' of ↵Linus Torvalds1-14/+0
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: - Remove code I accidentally applied when doing a minor fix up to a patch, and then using "git commit -a --amend", which pulled in some other changes I was playing with. - Remove an used variable in trace_events_inject code - Fix function graph tracer when it traces a ftrace direct function. It will now ignore tracing a function that has a ftrace direct tramploine attached. This is needed for eBPF to use the ftrace direct code. * tag 'trace-v5.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace: Fix function_graph tracer interaction with BPF trampoline tracing: remove set but not used variable 'buffer' module: Remove accidental change of module_enable_x()
2019-12-11s390/kasan: add KASAN_VMALLOC supportVasily Gorbik2-12/+57
Add KASAN_VMALLOC support which now enables vmalloc memory area access checks as well as enables usage of VMAP_STACK under kasan. KASAN_VMALLOC changes the way vmalloc and modules areas shadow memory is handled. With this new approach only top level page tables are pre-populated and lower levels are filled dynamically upon memory allocation. Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390: remove last diag 0x44 callerHeiko Carstens3-26/+5
diag 0x44 is a voluntary undirected yield of a virtual CPU. This has caused a lot of performance issues in the past. There is only one caller left, and that one is only executed if diag 0x9c (directed yield) is not present. Given that all hypervisors implement diag 0x9c anyway, remove the last diag 0x44 to avoid that more callers will be added. Worst case that could happen now, if diag 0x9c is not present, is that a virtual CPU would loop a bit instead of giving its time slice up. diag 0x44 statistics in debugfs are kept and will always be zero, so that user space can tell that there are no calls. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390/uv: use EOPNOTSUPP instead of ENOTSUPPChristian Borntraeger1-1/+1
ENOTSUP is just an internal kernel error and should never reach userspace. The return value of the share function is not exported to userspace, but to avoid giving bad examples let us use EOPNOTSUPP: Suggested-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390/cpum_sf: Avoid SBD overflow condition in irq handlerThomas Richter1-6/+0
The s390 CPU Measurement sampling facility has an overflow condition which fires when all entries in a SBD are used. The measurement alert interrupt is triggered and reads out all samples in this SDB. It then tests the successor SDB, if this SBD is not full, the interrupt handler does not read any samples at all from this SDB The design waits for the hardware to fill this SBD and then trigger another meassurement alert interrupt. This scheme works nicely until an perf_event_overflow() function call discards the sample due to a too high sampling rate. The interrupt handler has logic to read out a partially filled SDB when the perf event overflow condition in linux common code is met. This causes the CPUM sampling measurement hardware and the PMU device driver to operate on the same SBD's trailer entry. This should not happen. This can be seen here using this trace: cpumsf_pmu_add: tear:0xb5286000 hw_perf_event_update: sdbt 0xb5286000 full 1 over 0 flush_all:0 hw_perf_event_update: sdbt 0xb5286008 full 0 over 0 flush_all:0 above shows 1. interrupt hw_perf_event_update: sdbt 0xb5286008 full 1 over 0 flush_all:0 hw_perf_event_update: sdbt 0xb5286008 full 0 over 0 flush_all:0 above shows 2. interrupt ... this goes on fine until... hw_perf_event_update: sdbt 0xb5286068 full 1 over 0 flush_all:0 perf_push_sample1: overflow one or more samples read from the IRQ handler are rejected by perf_event_overflow() and the IRQ handler advances to the next SDB and modifies the trailer entry of a partially filled SDB. hw_perf_event_update: sdbt 0xb5286070 full 0 over 0 flush_all:1 timestamp: 14:32:52.519953 Next time the IRQ handler is called for this SDB the trailer entry shows an overflow count of 19 missed entries. hw_perf_event_update: sdbt 0xb5286070 full 1 over 19 flush_all:1 timestamp: 14:32:52.970058 Remove access to a follow on SDB when event overflow happened. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390/cpum_sf: Adjust sampling interval to avoid hitting sample limitsThomas Richter1-0/+16
Function perf_event_ever_overflow() and perf_event_account_interrupt() are called every time samples are processed by the interrupt handler. However function perf_event_account_interrupt() has checks to avoid being flooded with interrupts (more then 1000 samples are received per task_tick). Samples are then dropped and a PERF_RECORD_THROTTLED is added to the perf data. The perf subsystem limit calculation is: maximum sample frequency := 100000 --> 1 samples per 10 us task_tick = 10ms = 10000us --> 1000 samples per task_tick The work flow is measurement_alert() uses SDBT head and each SBDT points to 511 SDB pages, each with 126 sample entries. After processing 8 SBDs and for each valid sample calling: perf_event_overflow() perf_event_account_interrupts() there is a considerable amount of samples being dropped, especially when the sample frequency is very high and near the 100000 limit. To avoid the high amount of samples being dropped near the end of a task_tick time frame, increment the sampling interval in case of dropped events. The CPU Measurement sampling facility on the s390 supports only intervals, specifiing how many CPU cycles have to be executed before a sample is generated. Increase the interval when the samples being generated hit the task_tick limit. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390/test_unwind: fix spelling mistake "reqister" -> "register"Colin Ian King1-1/+1
There is a spelling mistake in a pr_info message. Fix it. Link: https://lkml.kernel.org/r/20191202090215.28766-1-colin.king@canonical.com Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11s390/spinlock: remove confusing comment in arch_spin_lock_waitVasily Gorbik1-1/+0
arch_spin_lock_wait does not take steal time into consideration. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-11Merge tag 'arm-soc/for-5.5/devicetree-fixes' of ↵Olof Johansson4-6/+6
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for v5.5-rc1, please pull the following: - Nicolas fixes the SoC's dma-range property to cover the full 1GB aperture - Stefan fixes the critical temperature trip point to be set before the firmware performs thermal throttling - Florian fixes the BCM5301X and Cygnus MDIO nodes to have corrected #address-cells and #size-cells properties * tag 'arm-soc/for-5.5/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: bcm283x: Fix critical trip point ARM: dts: Cygnus: Fix MDIO node address/size cells ARM: dts: bcm2711: fix soc's node dma-ranges ARM: dts: BCM5301X: Fix MDIO node address/size cells Link: https://lore.kernel.org/r/20191210205850.12442-1-f.fainelli@gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-11ARM: mmp: include the correct cputype.hArnd Bergmann1-1/+1
The file was moved, causing a build error: In file included from /git/arm-soc/arch/arm/mach-mmp/pxa168.c:28: arch/arm/mach-mmp/pxa168.h:22:10: fatal error: cputype.h: No such file or directory Include it from the new location. Link: https://lore.kernel.org/r/20191210203409.2875880-1-arnd@arndb.de Fixes: 32adcaa010fa ("ARM: mmp: move cputype.h to include/linux/soc/") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-11ARM: dts: am437x-gp/epos-evm: fix panel compatibleTomi Valkeinen2-2/+2
The LCD panel on AM4 GP EVMs and ePOS boards seems to be osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly the panel has changed since the early EVMs, or there has been a mistake with the panel type. Update the DT files accordingly. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-11bpf, mips: Limit to 33 tail callsPaul Chaignon1-4/+5
All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in MIPS' JIT compiler to allow 33 tail calls. Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Reported-by: Mahshid Khezri <khezri.mahshid@gmail.com> Signed-off-by: Paul Chaignon <paul.chaignon@orange.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/b8eb2caac1c25453c539248e56ca22f74b5316af.1575916815.git.paul.chaignon@gmail.com
2019-12-11bpf, riscv: Limit to 33 tail callsPaul Chaignon1-2/+2
All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in RISC-V's JIT compiler to allow 33 tail calls. I tested it using the above selftest on an emulated RISCV64. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Reported-by: Mahshid Khezri <khezri.mahshid@gmail.com> Signed-off-by: Paul Chaignon <paul.chaignon@orange.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Björn Töpel <bjorn.topel@gmail.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com
2019-12-11arm64: dts: ls1028a: fix typo in TMU calibration dataMichael Walle1-1/+1
The temperature sensor may jump backwards because there is a wrong calibration value. Both values have to be monotonically increasing. Fix it. This was tested on a custom board. Fixes: 571cebfe8e2b ("arm64: dts: ls1028a: Add Thermal Monitor Unit node") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Tang Yuantian <andy.tang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-11ARM: imx: Correct ocotp id for serial number support of i.MX6ULL/ULZ SoCsChristoph Niedermaier1-2/+2
After the commit 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs") the kernel doesn't start on i.MX6ULL/ULZ SoC. Tested on next-20191205. For i.MX6ULL/ULZ the variable "ocotp_compat" is set to "fsl,imx6ul-ocotp", but with commit ffbc34bf0e9c ("nvmem: imx-ocotp: Implement i.MX6ULL/ULZ support") and commit f243bc821ee3 ("ARM: dts: imx6ull: Fix i.MX6ULL/ULZ ocotp compatible") the value "fsl,imx6ull-ocotp" is already defined and set in device tree... By setting "ocotp_compat" to "fsl,imx6ull-ocotp" the kernel does boot. Fixes: 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs") Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-12-10sh: kgdb: Mark expected switch fall-throughsKuninori Morimoto1-0/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following error: LINUX/arch/sh/kernel/kgdb.c: In function 'kgdb_arch_handle_exception': LINUX/arch/sh/kernel/kgdb.c:267:6: error: this statement may fall through [-Werror=implicit-fallthrough=] if (kgdb_hex2long(&ptr, &addr)) ^ LINUX/arch/sh/kernel/kgdb.c:269:2: note: here case 'D': ^~~~ Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-12-10ARM: dts: bcm283x: Fix critical trip pointStefan Wahren1-1/+1
During definition of the CPU thermal zone of BCM283x SoC family there was a misunderstanding of the meaning "criticial trip point" and the thermal throttling range of the VideoCore firmware. The latter one takes effect when the core temperature is at least 85 degree celsius or higher So the current critical trip point doesn't make sense, because the thermal shutdown appears before the firmware has a chance to throttle the ARM core(s). Fix these unwanted shutdowns by increasing the critical trip point to a value which shouldn't be reached with working thermal throttling. Fixes: 0fe4d2181cc4 ("ARM: dts: bcm283x: Add CPU thermal zone with 1 trip point") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-12-10ftrace: Fix function_graph tracer interaction with BPF trampolineAlexei Starovoitov1-14/+0
Depending on type of BPF programs served by BPF trampoline it can call original function. In such case the trampoline will skip one stack frame while returning. That will confuse function_graph tracer and will cause crashes with bad RIP. Teach graph tracer to skip functions that have BPF trampoline attached. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-12-10ARM: omap2plus_defconfig: Add back DEBUG_FSTony Lindgren1-0/+1
Commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") removed select for DEBUG_FS but we still need it at least for enabling deeper idle states for the SoCs. Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-10ARM: omap2plus_defconfig: enable NET_SWITCHDEVGrygorii Strashko1-1/+2
The TI_CPSW_SWITCHDEV definition in Kconfig was changed from "select NET_SWITCHDEV" to "depends on NET_SWITCHDEV", and therefore it is required to explicitelly enable NET_SWITCHDEV config option in omap2plus_defconfig. Fixes: 3727d259ddaf ("arm: omap2plus_defconfig: enable new cpsw switchdev driver") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-10ARM: dts: am335x-sancloud-bbe: fix phy modeMans Rullgard1-1/+1
The phy mode should be rgmii-id. For some reason, it used to work with rgmii-txid but doesn't any more. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-10drivers: Fix boot problem on SuperHGuenter Roeck1-9/+2
SuperH images crash too eearly to display any console output. Bisect points to commit 507fd01d5333 ("drivers: move the early platform device support to arch/sh"). An analysis of that patch suggests that early_platform_cleanup() is now called at the wrong time. Restoring its call point fixes the problem. Cc: Bartosz Golaszewski <brgl@bgdev.pl> Fixes: 507fd01d5333 ("drivers: move the early platform device support to arch/sh") Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Rob Landley <rob@landley.net> Link: https://lore.kernel.org/r/20191203205852.15659-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-09treewide: Use sizeof_field() macroPankaj Bharadiya5-18/+18
Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except at places where these are defined. Later patches will remove the unused definition of FIELD_SIZEOF(). This patch is generated using following script: EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h" git grep -l -e "\bFIELD_SIZEOF\b" | while read file; do if [[ "$file" =~ $EXCLUDE_FILES ]]; then continue fi sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file; done Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: David Miller <davem@davemloft.net> # for net
2019-12-09MIPS: OCTEON: Replace SIZEOF_FIELD() macroPankaj Bharadiya1-8/+1
Switch to the standard sizeof_field() macro to find the size of a member of a struct and remove the custom SIZEOF_FIELD() macro. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Link: https://lore.kernel.org/r/20190924105839.110713-4-pankaj.laxminarayan.bharadiya@intel.com Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2019-12-09ARM: dts: Cygnus: Fix MDIO node address/size cellsFlorian Fainelli1-2/+2
The MDIO node on Cygnus had an reversed #address-cells and #size-cells properties, correct those. Fixes: 40c26d3af60a ("ARM: dts: Cygnus: Add the ethernet switch and ethernet PHY") Reported-by: Simon Horman <simon.horman@netronome.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-12-09ARM: dts: bcm2711: fix soc's node dma-rangesNicolas Saenz Julienne1-1/+1
Raspberry Pi's firmware has a feature to select how much memory to reserve for its GPU called 'gpu_mem'. The possible values go from 16MB to 944MB, with a default of 64MB. This memory resides in the topmost part of the lower 1GB memory area and grows bigger expanding towards the begging of memory. It turns out that with low 'gpu_mem' values (16MB and 32MB) the size of the memory available to the system in the lower 1GB area can outgrow the interconnect's dma-range as its size was selected based on the maximum system memory available given the default gpu_mem configuration. This makes that memory slice unavailable for DMA. And may cause nasty kernel warnings if CMA happens to include it. Change soc's dma-ranges to really reflect it's HW limitation, which is being able to only DMA to the lower 1GB area. Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 16:04:28 +0000