summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-08-14perf tools: Add NO_LIBCAP=1 to the minimal build testArnaldo Carvalho de Melo
We need to add these so that we test building without all selectable features. Acked-by: Igor Lubashev <ilubashe@akamai.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Link: https://lkml.kernel.org/n/tip-eknnvp22elznj0cl5a39hc4v@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-08-14Bluetooth: hci_qca: Skip 1 error print in device_want_to_sleep()Rocky Liao
Don't fall through to print error message when receive sleep indication in HCI_IBS_RX_ASLEEP state, this is allowed behavior. Signed-off-by: Rocky Liao <rjliao@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-08-14perf tools: Add helpers to use capabilities if presentIgor Lubashev
Add utilities to help checking capabilities of the running procss. Make perf link with libcap, if it is available. If no libcap-dev[el], fallback to the geteuid() == 0 test used before. Committer notes: $ perf test python 18: 'import perf' in python : FAILED! $ perf test -v python Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc 18: 'import perf' in python : --- start --- test child forked, pid 23288 Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /tmp/build/perf/python/perf.so: undefined symbol: cap_get_flag test child finished with -1 ---- end ---- 'import perf' in python: FAILED! $ This happens because differently from the perf binary generated with this patch applied: $ ldd /tmp/build/perf/perf | grep libcap libcap.so.2 => /lib64/libcap.so.2 (0x00007f724a4ef000) $ The python binding isn't linking with libcap: $ ldd /tmp/build/perf/python/perf.so | grep libcap $ So add 'cap' to the 'extra_libraries' variable in tools/perf/util/setup.py, and rebuild: $ perf test python 18: 'import perf' in python : Ok $ If we explicitely disable libcap it also continues to work: $ make NO_LIBCAP=1 -C tools/perf O=/tmp/build/perf install-bin $ ldd /tmp/build/perf/perf | grep libcap $ ldd /tmp/build/perf/python/perf.so | grep libcap $ perf test python 18: 'import perf' in python : Ok $ Signed-off-by: Igor Lubashev <ilubashe@akamai.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: linux-arm-kernel@lists.infradead.org [ split from a larger patch ] Link: http://lkml.kernel.org/r/8a1e76cf5c7c9796d0d4d240fbaa85305298aafa.1565188228.git.ilubashe@akamai.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2019-08-14Merge tag 'ux500-v5.4-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into arm/soc This is a slew of Ux500 updates for the v5.4 kernel cycle: - Stop populating the PRCMU devices from the core CPU file, it works just fine at device_initcall() level. - Add a missing of_node_put() in the core file. - Simplify the debug UART code. - Add myself to MAINTAINERS * tag 'ux500-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson: MAINTAINERS: add soc/ux500 ARM: ux500: simplify and move debug UART ARM: ux500: add missing of_node_put() ARM: ux500: Stop populating the PRCMU devices early Link: https://lore.kernel.org/r/CACRpkdbH-h5fRwuidcpeOp8mtRoKUW65SAk8a4A==BCDzn3QMA@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: iop32x: merge everything into mach-iop32x/Arnd Bergmann
Various bits of iop32x are now in their traditional locations in plat-iop, mach-iop/include/mach/ and in include/asm/mach/hardware. As nothing outside of the iop32x mach code references these any more, this can all be moved into one place now. The only remaining things in the include/mach/ directory are now the NR_IRQS definition, the entry-macros.S file and the the decompressor uart access. After the irqchip code has been converted to SPARSE_IRQ and GENERIC_IRQ_MULTI_HANDLER, it can be moved to ARCH_MULTIPLATFORM. Link: https://lore.kernel.org/r/20190809163334.489360-7-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: iop32x: make mach/uncompress.h independent of mach/hardware.hArnd Bergmann
All supported uarts use the same address: IQ80321_UART and IQ31244_UART are both defined to the default value of 0xfe800000. By using that as the address unconditionally, all dependencies on other machine headers can be avoided. Link: https://lore.kernel.org/r/20190809163334.489360-6-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: xscale: fix multi-cpu compilationArnd Bergmann
Building a combined ARMv4+XScale kernel produces these and other build failures: /tmp/copypage-xscale-3aa821.s: Assembler messages: /tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode /tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode /tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode /tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode /tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode /tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode /tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode Add an explict .arch armv5 in the inline assembly to allow the ARMv5 specific instructions regardless of the compiler -march= target. Link: https://lore.kernel.org/r/20190809163334.489360-5-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14dma: iop-adma: allow building without platform headersArnd Bergmann
Now that iop3xx and iop13xx are gone, the iop-adma driver no longer needs to deal with incompatible register layout defined in machine specific header files. Move the iop32x specific definitions into drivers/dma/iop-adma.h and the platform_data into include/linux/platform_data/dma-iop32x.h, and change the machine code to no longer reference those. The DMA0_ID/DMA1_ID/AAU_ID macros are required as part of the platform data interface and still need to be visible, so move those from one header to the other. Link: https://lore.kernel.org/r/20190809163334.489360-4-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14dmaengine: iop-adma: use correct printk format stringsArnd Bergmann
When compile-testing on other architectures, we get lots of warnings about incorrect format strings, like: drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots': drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy': >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=] Use %zu for printing size_t as required, and cast the dma_addr_t arguments to 'u64' for printing with %llx. Ideally this should use the %pad format string, but that requires an lvalue argument that doesn't work here. Link: https://lore.kernel.org/r/20190809163334.489360-3-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14dmaengine: iop-adma: include prefetch.hArnd Bergmann
Compile-testing this driver fails on m68k without the extra header inclusion. Link: https://lore.kernel.org/r/20190809163334.489360-2-arnd@arndb.de Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: remove Intel iop33x and iop13xx supportArnd Bergmann
There are three families of IOP machines we support in Linux: iop32x (which includes EP80219), iop33x and iop13xx (aka IOP34x aka WP8134x). All products we support in the kernel are based on the first of these, iop32x, the other families only ever supported the Intel reference boards but no actual machine anyone could ever buy. While one could clearly make them all three work in a single kernel with some work, this takes the easy way out, removing the later two platforms entirely, under the assumption that there are no remaining users. Earlier versions of OpenWRT and Debian both had support for iop32x but not the others, and they both dropped iop32x as well in their 2015 releases. Link: https://lore.kernel.org/r/20190809163334.489360-1-arnd@arndb.de Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C parts Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Martin Michlmayr <tbm@cyrius.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14dt-bindings: gpio: Document GPIOs via Moxtet busMarek Behún
This patch adds documentation of the device tree bindings for GPIOs on the devices connected via Moxtet bus. Link: https://lore.kernel.org/r/20190812161118.21476-6-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14drivers: gpio: Add support for GPIOs over Moxtet busMarek Behún
This adds support for interpreting the input and output bits of one device on Moxtet bus as GPIOs. This is needed for example by the SFP cage module of Turris Mox. Link: https://lore.kernel.org/r/20190812161118.21476-5-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14bus: moxtet: Add sysfs and debugfs documentationMarek Behún
Add sysfs ABI documentation for the attribute files module_id and module_name Add debugfs ABI documentation for reading input from the shift registers and reading last written output or write output to the shift registers. Link: https://lore.kernel.org/r/20190812161118.21476-4-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14dt-bindings: bus: Document moxtet bus bindingMarek Behún
This adds device tree binding documentation for the Moxtet bus, a bus via which the different modules connected to the Turris Mox router can be configured. Link: https://lore.kernel.org/r/20190812161118.21476-3-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14bus: Add support for Moxtet busMarek Behún
On the Turris Mox router different modules can be connected to the main CPU board: currently a module with a SFP cage, a module with MiniPCIe connector, a PCIe pass-through MiniPCIe connector module, a 4-port switch module, an 8-port switch module, and a 4-port USB3 module. For example: [CPU]-[PCIe-pass-through]-[PCIe]-[8-port switch]-[8-port switch]-[SFP] Each of this modules has an input and output shift register, and these are connected via SPI to the CPU board. Via SPI we are able to discover which modules are connected, in which order, and we can also read some information about the modules (eg. their interrupt status), and configure them. From each module 8 bits can be read (of which low 4 bits identify the module) and 8 bits can be written. For example from the module with a SFP cage we can read the LOS, TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and RATE-SELECT signals. This driver creates a new bus type, called "moxtet". For each Mox module it finds via SPI, it creates a new device on the moxtet bus so that drivers can be written for them. It also implements a virtual interrupt controller for the modules which send their interrupt status over the SPI shift register. These modules do this in addition to sending their interrupt status via the shared interrupt line. When the shared interrupt is triggered, we read from the shift register and handle IRQs for all devices which are in interrupt. The topology of how Mox modules are connected can then be read by listing /sys/bus/moxtet/devices. Link: https://lore.kernel.org/r/20190812161118.21476-2-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14Merge tag 'renesas-drivers-for-v5.4-tag1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers Renesas driver updates for v5.4 - Fix a flexible array member definition in the R-Car SYSC driver. * tag 'renesas-drivers-for-v5.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: rcar-sysc: Use [] to denote a flexible array member Link: https://lore.kernel.org/r/20190802120355.1430-3-geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14Merge tag 'renesas-arm64-dt-for-v5.4-tag1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/dt Renesas ARM64 DT updates for v5.4 - CAN, BT, and WLAN support for the HiHope RZ/G2[MN] boards, - Sound support for RZ/G2M, - Sort nodes in various SoC and board DTSes, - Small fixes and improvements. * tag 'renesas-arm64-dt-for-v5.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: (23 commits) arm64: dts: renesas: ulcb: Sort nodes arm64: dts: renesas: ulcb-kf: Sort nodes arm64: dts: renesas: salvator-common: Sort nodes arm64: dts: renesas: r8a7796: salvator-xs: Sort nodes arm64: dts: renesas: r8a7796: salvator-x: Sort nodes arm64: dts: renesas: r8a7795: salvator-xs: Sort nodes arm64: dts: renesas: r8a7795: salvator-x: Sort nodes arm64: dts: renesas: r8a7795-es1: salvator-x: Sort nodes arm64: dts: renesas: r8a77965: Sort nodes arm64: dts: renesas: r8a7795-es1: Sort nodes arm64: dts: renesas: r8a7795: Sort nodes arm64: dts: renesas: r8a774a1: Add SSIU support for sound arm64: dts: renesas: r8a774a1: Use extended audio dmac registers arm64: dts: renesas: hihope-common: Add WLAN support arm64: dts: renesas: hihope-common: Add BT support arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander arm64: dts: renesas: hihope-rzg2-ex: Enable CAN interfaces arm64: dts: renesas: r8a774a1: Add CANFD support arm64: dts: renesas: r8a774a1: Add missing assigned-clocks for CAN[01] arm64: dts: renesas: r8a774c0: Add missing assigned-clocks for CAN[01] ... Link: https://lore.kernel.org/r/20190802120355.1430-2-geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14Merge tag 'stm32-defconfig-for-v5.4-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/defconfig STM32 defconfig updates for v5.4, round 1 Highlights: ---------- -Enable FMC2 NAND (used for STM32MP socs) -Enable STM32 booster regulator as module -Enable STM32 QSPI as module * tag 'stm32-defconfig-for-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: multi_v7_defconfig: Enable SPI_STM32_QSPI support ARM: multi_v7_defconfig: enable STM32 booster regulator ARM: multi_v7_defconfig: add FMC2 NAND controller support Link: https://lore.kernel.org/r/b164eaa8-4553-9c0f-0729-2ecc96fbae7a@st.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: multi_v7_defconfig: Enable SPI_STM32_QSPI supportPatrice Chotard
Enable support for QSPI block on STM32 SoCs. Link: https://lore.kernel.org/r/20190731072204.32160-1-patrice.chotard@st.com Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: remove w90x900 platformArnd Bergmann
This removes the old Winbond w90x900 platform, also known as Nuvoton NUC900. Wan Zongshun originally contributed the port and maintained it since then. From all I can tell, this platform is no longer being used with modern kernels, based on various indications: - The supported chips (nuc910/950/960) are no longer marketed by the manufacturer - Newer chips from the same family (nuc97x, nuc980, n329x) that are still marketed have Linux BSPs but those were never submitted for upstream inclusion. - The last patch from the platform maintainer was in 2011. - All patches to w90x900 platform specific files afterwards are cleanups that were apparently done without access to test hardware. - Both the website and the email address listed in the MAINTAINERS have become unreachable. Link: https://lore.kernel.org/r/20190809202749.742267-17-arnd@arndb.de Cc: "Wanzongshun (Vincent)" <wanzongshun@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: remove ks8695 platformArnd Bergmann
ks8695 is an older SoC originally made by Kendin, which was later acquired by Micrel, and subsequently by Microchip. The platform port was originally contributed by Andrew Victor and Ben Dooks, and later maintained by Greg Ungerer. When I recently submitted cleanups, but Greg noted that the platform no longer boots and nobody is using it any more, we decided to remove it. Link: https://lore.kernel.org/r/20190809202749.742267-2-arnd@arndb.de Cc: Andrew Victor <linux@maxim.org.za> Acked-by: Ben Dooks <ben-linux@fluff.org> Link: https://wikidevi.com/wiki/Micrel Link: https://lore.kernel.org/linux-arm-kernel/2bc41895-d4f9-896c-0726-0b2862fcbf25@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Ungerer <gerg@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driverLorenzo Pieralisi
Enable the PSCI CPUidle driver to replace the functionality previously provided by the generic ARM CPUidle driver. Link: https://lore.kernel.org/r/20190814125239.6270-3-lorenzo.pieralisi@arm.com Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14arm64: defconfig: Enable the PSCI CPUidle driverLorenzo Pieralisi
Enable the PSCI CPUidle driver to replace the functionality previously provided by the generic ARM CPUidle driver through CPU operations. Link: https://lore.kernel.org/r/20190814125239.6270-2-lorenzo.pieralisi@arm.com Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-14i2c: stm32: Use the correct style for SPDX License IdentifierNishad Kamdar
This patch corrects the SPDX License Identifier style in header file related to STM32 Driver for I2C hardware bus support. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-14i2c: emev2: avoid race when unregistering slave clientWolfram Sang
After we disabled interrupts, there might still be an active one running. Sync before clearing the pointer to the slave device. Fixes: c31d0a00021d ("i2c: emev2: add slave support") Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-14i2c: rcar: avoid race when unregistering slave clientWolfram Sang
After we disabled interrupts, there might still be an active one running. Sync before clearing the pointer to the slave device. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Krzysztof Adamski <krzysztof.adamski@nokia.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-14arm64: memory: Cosmetic cleanupsWill Deacon
Cleanup memory.h so that the indentation is consistent, remove pointless line-wrapping and use consistent parameter names for different versions of the same macro. Reviewed-by: Steve Capper <steve.capper@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Add comments to end of non-trivial #ifdef blocksWill Deacon
Commenting the #endif of a multi-statement #ifdef block with the condition which guards it is useful and can save having to scroll back through the file to figure out which set of Kconfig options apply to a particular piece of code. Reviewed-by: Steve Capper <steve.capper@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Implement __tag_set() as common functionWill Deacon
There's no need for __tag_set() to be a complicated macro when CONFIG_KASAN_SW_TAGS=y and a simple static inline otherwise. Rewrite the thing as a common static inline function. Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Simplify _VA_START and _PAGE_OFFSET definitionsWill Deacon
Rather than subtracting from -1 and then adding 1, we can simply subtract from 0. Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Simplify virt_to_page() implementationWill Deacon
Build virt_to_page() on top of virt_to_pfn() so we can avoid the need for explicit shifting. Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Rewrite default page_to_virt()/virt_to_page()Will Deacon
The default implementations of page_to_virt() and virt_to_page() are fairly confusing to read and the former evaluates its 'page' parameter twice in the macro Rewrite them so that the computation is expressed as 'base + index' in both cases and the parameter is always evaluated exactly once. Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Ensure address tag is masked in conversion macrosWill Deacon
When converting a linear virtual address to a physical address, pfn or struct page *, we must make sure that the tag bits are masked before the calculation otherwise we end up with corrupt pointers when running with CONFIG_KASAN_SW_TAGS=y: | Unable to handle kernel paging request at virtual address 0037fe0007580d08 | [0037fe0007580d08] address between user and kernel address ranges Mask out the tag in __virt_to_phys_nodebug() and virt_to_page(). Reported-by: Qian Cai <cai@lca.pw> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Fixes: 9cb1c5ddd2c4 ("arm64: mm: Remove bit-masking optimisations for PAGE_OFFSET and VMEMMAP_START") Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14arm64: memory: Fix virt_addr_valid() using __is_lm_address()Will Deacon
virt_addr_valid() is intended to test whether or not the passed address is a valid linear map address. Unfortunately, it relies on _virt_addr_is_linear() which is broken because it assumes the linear map is at the top of the address space, which it no longer is. Reimplement virt_addr_valid() using __is_lm_address() and remove _virt_addr_is_linear() entirely. At the same time, ensure we evaluate the macro parameter only once and move it within the __ASSEMBLY__ block. Reported-by: Qian Cai <cai@lca.pw> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Steve Capper <steve.capper@arm.com> Reviewed-by: Steve Capper <steve.capper@arm.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Fixes: 14c127c957c1 ("arm64: mm: Flip kernel VA space") Signed-off-by: Will Deacon <will@kernel.org>
2019-08-14rxrpc: Fix read-after-free in rxrpc_queue_local()David Howells
rxrpc_queue_local() attempts to queue the local endpoint it is given and then, if successful, prints a trace line. The trace line includes the current usage count - but we're not allowed to look at the local endpoint at this point as we passed our ref on it to the workqueue. Fix this by reading the usage count before queuing the work item. Also fix the reading of local->debug_id for trace lines, which must be done with the same consideration as reading the usage count. Fixes: 09d2bf595db4 ("rxrpc: Add a tracepoint to track rxrpc_local refcounting") Reported-by: syzbot+78e71c5bab4f76a6a719@syzkaller.appspotmail.com Signed-off-by: David Howells <dhowells@redhat.com>
2019-08-14rxrpc: Fix local endpoint replacementDavid Howells
When a local endpoint (struct rxrpc_local) ceases to be in use by any AF_RXRPC sockets, it starts the process of being destroyed, but this doesn't cause it to be removed from the namespace endpoint list immediately as tearing it down isn't trivial and can't be done in softirq context, so it gets deferred. If a new socket comes along that wants to bind to the same endpoint, a new rxrpc_local object will be allocated and rxrpc_lookup_local() will use list_replace() to substitute the new one for the old. Then, when the dying object gets to rxrpc_local_destroyer(), it is removed unconditionally from whatever list it is on by calling list_del_init(). However, list_replace() doesn't reset the pointers in the replaced list_head and so the list_del_init() will likely corrupt the local endpoints list. Fix this by using list_replace_init() instead. Fixes: 730c5fd42c1e ("rxrpc: Fix local endpoint refcounting") Reported-by: syzbot+193e29e9387ea5837f1d@syzkaller.appspotmail.com Signed-off-by: David Howells <dhowells@redhat.com>
2019-08-14MAINTAINERS: i2c-imx: take over maintainershipOleksij Rempel
I would like to maintain the i2c-imx driver. Since I work with different i.MX variants and have access to the hardware, I can spend some time on the reviewing of this driver. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-14Revert "i2c: imx: improve the error handling in i2c_imx_dma_request()"Fabio Estevam
Since commit e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") when booting with the DMA driver as module (such as CONFIG_FSL_EDMA=m) the following endless clk warnings are seen: [ 153.077831] ------------[ cut here ]------------ [ 153.082528] WARNING: CPU: 0 PID: 15 at drivers/clk/clk.c:924 clk_core_disable_lock+0x18/0x24 [ 153.093077] i2c0 already disabled [ 153.096416] Modules linked in: [ 153.099521] CPU: 0 PID: 15 Comm: kworker/0:1 Tainted: G W 5.2.0+ #321 [ 153.107290] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 153.113772] Workqueue: events deferred_probe_work_func [ 153.118979] [<c0019560>] (unwind_backtrace) from [<c0014734>] (show_stack+0x10/0x14) [ 153.126778] [<c0014734>] (show_stack) from [<c083f8dc>] (dump_stack+0x9c/0xd4) [ 153.134051] [<c083f8dc>] (dump_stack) from [<c0031154>] (__warn+0xf8/0x124) [ 153.141056] [<c0031154>] (__warn) from [<c0031248>] (warn_slowpath_fmt+0x38/0x48) [ 153.148580] [<c0031248>] (warn_slowpath_fmt) from [<c040fde0>] (clk_core_disable_lock+0x18/0x24) [ 153.157413] [<c040fde0>] (clk_core_disable_lock) from [<c058f520>] (i2c_imx_probe+0x554/0x6ec) [ 153.166076] [<c058f520>] (i2c_imx_probe) from [<c04b9178>] (platform_drv_probe+0x48/0x98) [ 153.174297] [<c04b9178>] (platform_drv_probe) from [<c04b7298>] (really_probe+0x1d8/0x2c0) [ 153.182605] [<c04b7298>] (really_probe) from [<c04b7554>] (driver_probe_device+0x5c/0x174) [ 153.190909] [<c04b7554>] (driver_probe_device) from [<c04b58c8>] (bus_for_each_drv+0x44/0x8c) [ 153.199480] [<c04b58c8>] (bus_for_each_drv) from [<c04b746c>] (__device_attach+0xa0/0x108) [ 153.207782] [<c04b746c>] (__device_attach) from [<c04b65a4>] (bus_probe_device+0x88/0x90) [ 153.215999] [<c04b65a4>] (bus_probe_device) from [<c04b6a04>] (deferred_probe_work_func+0x60/0x90) [ 153.225003] [<c04b6a04>] (deferred_probe_work_func) from [<c004f190>] (process_one_work+0x204/0x634) [ 153.234178] [<c004f190>] (process_one_work) from [<c004f618>] (worker_thread+0x20/0x484) [ 153.242315] [<c004f618>] (worker_thread) from [<c0055c2c>] (kthread+0x118/0x150) [ 153.249758] [<c0055c2c>] (kthread) from [<c00090b4>] (ret_from_fork+0x14/0x20) [ 153.257006] Exception stack(0xdde43fb0 to 0xdde43ff8) [ 153.262095] 3fa0: 00000000 00000000 00000000 00000000 [ 153.270306] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 153.278520] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 153.285159] irq event stamp: 3323022 [ 153.288787] hardirqs last enabled at (3323021): [<c0861c4c>] _raw_spin_unlock_irq+0x24/0x2c [ 153.297261] hardirqs last disabled at (3323022): [<c040d7a0>] clk_enable_lock+0x10/0x124 [ 153.305392] softirqs last enabled at (3322092): [<c000a504>] __do_softirq+0x344/0x540 [ 153.313352] softirqs last disabled at (3322081): [<c00385c0>] irq_exit+0x10c/0x128 [ 153.320946] ---[ end trace a506731ccd9bd703 ]--- This endless clk warnings behaviour is well explained by Andrey Smirnov: "Allocating DMA after registering I2C adapter can lead to infinite probing loop, for example, consider the following scenario: 1. i2c_imx_probe() is called and successfully registers an I2C adapter via i2c_add_numbered_adapter() 2. As a part of i2c_add_numbered_adapter() new I2C slave devices are added from DT which results in a call to driver_deferred_probe_trigger() 3. i2c_imx_probe() continues and calls i2c_imx_dma_request() which due to lack of proper DMA driver returns -EPROBE_DEFER 4. i2c_imx_probe() fails, removes I2C adapter and returns -EPROBE_DEFER, which places it into deferred probe list 5. Deferred probe work triggered in #2 above kicks in and calls i2c_imx_probe() again thus bringing us to step #1" So revert commit e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") and restore the old behaviour, in order to avoid regressions on existing setups. Cc: <stable@vger.kernel.org> Reported-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reported-by: Russell King <linux@armlinux.org.uk> Fixes: e1ab9a468e3b ("i2c: imx: improve the error handling in i2c_imx_dma_request()") Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-14netfilter: nft_flow_offload: skip tcp rst and fin packetsPablo Neira Ayuso
TCP rst and fin packets do not qualify to place a flow into the flowtable. Most likely there will be no more packets after connection closure. Without this patch, this flow entry expires and connection tracking picks up the entry in ESTABLISHED state using the fixup timeout, which makes this look inconsistent to the user for a connection that is actually already closed. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2019-08-14Merge tag 'common/for-v5.4-rc1/cpu-topology' of ↵Will Deacon
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux into for-next/cpu-topology Pull in generic CPU topology changes from Paul Walmsley (RISC-V). * tag 'common/for-v5.4-rc1/cpu-topology' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: MAINTAINERS: Add an entry for generic architecture topology base: arch_topology: update Kconfig help description RISC-V: Parse cpu topology during boot. arm: Use common cpu_topology structure and functions. cpu-topology: Move cpu topology code to common code. dt-binding: cpu-topology: Move cpu-map to a common binding. Documentation: DT: arm: add support for sockets defining package boundaries
2019-08-14gpio: Fix build error of function redefinitionYueHaibing
when do randbuilding, I got this error: In file included from drivers/hwmon/pmbus/ucd9000.c:19:0: ./include/linux/gpio/driver.h:576:1: error: redefinition of gpiochip_add_pin_range gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name, ^~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/hwmon/pmbus/ucd9000.c:18:0: ./include/linux/gpio.h:245:1: note: previous definition of gpiochip_add_pin_range was here gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name, ^~~~~~~~~~~~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 964cb341882f ("gpio: move pincontrol calls to <linux/gpio/driver.h>") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190731123814.46624-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-14gpiolib: never report open-drain/source lines as 'input' to user-spaceBartosz Golaszewski
If the driver doesn't support open-drain/source config options, we emulate this behavior when setting the direction by calling gpiod_direction_input() if the default value is 0 (open-source) or 1 (open-drain), thus not actively driving the line in those cases. This however clears the FLAG_IS_OUT bit for the GPIO line descriptor and makes the LINEINFO ioctl() incorrectly report this line's mode as 'input' to user-space. This commit modifies the ioctl() to always set the GPIOLINE_FLAG_IS_OUT bit in the lineinfo structure's flags field. Since it's impossible to use the input mode and open-drain/source options at the same time, we can be sure the reported information will be correct. Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Cc: stable <stable@vger.kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190806114151.17652-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-14iommu/exynos: Remove __init annotation from exynos_sysmmu_probe()Marek Szyprowski
Exynos SYSMMU driver supports deferred probe. It happens when clocks needed for this driver are not yet available. Typically next calls to driver ->probe() happen before init section is free, but this is not really guaranteed. To make if safe, remove __init annotation from exynos_sysmmu_probe() function. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-14dt-bindings: gpio: aspeed: Add SGPIO supportHongwei Zhang
Add bindings to support SGPIO on AST2400 or AST2500. Signed-off-by: Hongwei Zhang <hongweiz@ami.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/1564603297-1391-2-git-send-email-hongweiz@ami.com [Adjusted when applying in several ways] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-14lib: Remove redundant ftrace flag removalMark Rutland
Since architectures can implement ftrace using a variety of mechanisms, generic code should always use CC_FLAGS_FTRACE rather than assuming that ftrace is built using -pg. Since commit: 2464a609ded09420 ("ftrace: do not trace library functions") ... lib/Makefile has removed CC_FLAGS_FTRACE from KBUILD_CFLAGS, so ftrace is disabled for all files under lib/. Given that, we shouldn't explicitly remove -pg when building lib/string.o, as this is redundant and bad form. Clean things up accordingly. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Coly Li <colyli@suse.de> Cc: Gary R Hook <gary.hook@amd.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Kent Overstreet <kent.overstreet@gmail.com> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Matthew Wilcox <willy@infradead.org> Link: https://lkml.kernel.org/r/20190806162539.51918-1-mark.rutland@arm.com
2019-08-14ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-upLuis Araneda
This fixes a kernel panic on memcpy when FORTIFY_SOURCE is enabled. The initial smp implementation on commit aa7eb2bb4e4a ("arm: zynq: Add smp support") used memcpy, which worked fine until commit ee333554fed5 ("ARM: 8749/1: Kconfig: Add ARCH_HAS_FORTIFY_SOURCE") enabled overflow checks at runtime, producing a read overflow panic. The computed size of memcpy args are: - p_size (dst): 4294967295 = (size_t) -1 - q_size (src): 1 - size (len): 8 Additionally, the memory is marked as __iomem, so one of the memcpy_* functions should be used for read/write. Fixes: aa7eb2bb4e4a ("arm: zynq: Add smp support") Signed-off-by: Luis Araneda <luaraneda@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-08-14ARM: zynq: Support smp in thumb modeLuis Araneda
Add .arm directive to headsmp.S to ensure that the CPU starts in 32-bit ARM mode and the correct code size is copied on smp bring-up. This is related to the fix applied to SoCFPGA by commit 5616f36713ea ("ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel") Additionally, start secondary CPUs on secondary_startup_arm to automatically switch from ARM to thumb on a thumb kernel Signed-off-by: Luis Araneda <luaraneda@gmail.com> Suggested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-08-14ALSA: hda - Add a generic reboot_notifyHui Wang
Make codec enter D3 before rebooting or poweroff can fix the noise issue on some laptops. And in theory it is harmless for all codecs to enter D3 before rebooting or poweroff, let us add a generic reboot_notify, then realtek and conexant drivers can call this function. Cc: stable@vger.kernel.org Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-14ALSA: hda - Let all conexant codec enter D3 when rebootingHui Wang
We have 3 new lenovo laptops which have conexant codec 0x14f11f86, these 3 laptops also have the noise issue when rebooting, after letting the codec enter D3 before rebooting or poweroff, the noise disappers. Instead of adding a new ID again in the reboot_notify(), let us make this function apply to all conexant codec. In theory make codec enter D3 before rebooting or poweroff is harmless, and I tested this change on a couple of other Lenovo laptops which have different conexant codecs, there is no side effect so far. Cc: stable@vger.kernel.org Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>