summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2019-09-05ARM: dts: aspeed: vesnin: Add secondary SPI flash chipIvan Mikhaylov1-0/+6
Adds secondary SPI flash chip into dts for vesnin. Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-09-05ARM: dts: aspeed: vesnin: Add wdt2 with alt-boot optionIvan Mikhaylov1-0/+4
Adds wdt2 section with 'alt-boot' option into dts for vesnin. Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-09-05ARM: dts: aspeed-g4: Add all flash chipsJoel Stanley1-0/+20
The FMC supports five chip selects, so describe the five possible flash chips. Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-09-04arm64: exynos: Enable exynos-chipid driverPankaj Dubey1-0/+1
Enable Exynos Chipid driver for accessing SoC related information. Link: https://lore.kernel.org/r/20190904175002.10487-6-krzk@kernel.org Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'samsung-soc-5.4-2' of ↵Arnd Bergmann4-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc Samsung mach/soc changes for v5.4 1. Minor fixup in plat and mach code (S3C platforms), 2. Enable exynos-chipid driver to provide SoC related information, 3. Extend the patterns for Samsung maintainer entries to cover all important files. * tag 'samsung-soc-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c ARM: exynos: Enable exynos-chipid driver ARM: samsung: Include GPIO driver header Link: https://lore.kernel.org/r/20190904175002.10487-5-krzk@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'samsung-dt-5.4-2' of ↵Arnd Bergmann6-4/+62
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM changes for v5.4, part 2 1. Fix Exynos542x Chromebooks boot with multi_v7 defconfig, 2. Add GPU (Mali) support to Exynos5250 boards, 3. Minor cleanup for Exynos3250 ADC. * tag 'samsung-dt-5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: dts: exynos: Enable GPU/Mali T604 on Arndale board ARM: dts: exynos: Enable GPU/Mali T604 on Chromebook Snow ARM: dts: exynos: Add GPU/Mali T604 node to Exynos5250 ARM: dts: exynos: Fix min/max buck4 for GPU on Arndale board ARM: dts: exynos: Mark LDO10 as always-on on Peach Pit/Pi Chromebooks ARM: dts: exynos: Remove not accurate secondary ADC compatible Link: https://lore.kernel.org/r/20190904175002.10487-4-krzk@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'samsung-defconfig-5.4' of ↵Arnd Bergmann2-2/+5
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/defconfig Samsung defconfig changes for v5.4 1. Enable AHCI platform driver on exynos defconfig for Exynos5250-based Arndale board, 2. Make Max77802 PMIC regulator driver a built-in on multi_v7 defconfig as it is essential early during boot. * tag 'samsung-defconfig-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in ARM: exynos_defconfig: Enable AHCI-platform SATA driver Link: https://lore.kernel.org/r/20190904175002.10487-2-krzk@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04riscv: Add perf callchain supportMao Han4-3/+101
This patch add support for perf callchain sampling on riscv platforms. The return address of leaf function is retrieved from pt_regs as it is not saved in the outmost frame. Signed-off-by: Mao Han <han_mao@c-sky.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Greentime Hu <green.hu@gmail.com> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: linux-riscv <linux-riscv@lists.infradead.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Guo Ren <guoren@kernel.org> Tested-by: Greentime Hu <greentime.hu@sifive.com> [paul.walmsley@sifive.com: fixed some 'checkpatch.pl --strict' issues; fixed patch description spelling] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-09-04ARM: dts: exynos: Enable GPU/Mali T604 on Arndale boardGuillaume Gardet1-0/+5
Tested with kmscube and some glmark2* tests on arndale board. Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04ARM: dts: exynos: Enable GPU/Mali T604 on Chromebook SnowGuillaume Gardet1-0/+5
Tested with kmscube and some glmark2* tests on Chromebook snow. Frequency adapts with load. Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04ARM: dts: exynos: Add GPU/Mali T604 node to Exynos5250Guillaume Gardet1-0/+47
Add nodes for GPU (Mali T604) to Exynos5250. Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04ARM: dts: exynos: Fix min/max buck4 for GPU on Arndale boardGuillaume Gardet1-2/+2
Required to have GPU voltage scaling working properly. Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-09-04Merge tag 'mvebu-dt64-5.4-2' of git://git.infradead.org/linux-mvebu into ↵Arnd Bergmann10-33/+985
arm/late mvebu dt64 for 5.4 (part 2) Add support for Turris Mox board (Armada 3720 SoC based) * tag 'mvebu-dt64-5.4-2' of git://git.infradead.org/linux-mvebu: (53 commits) arm64: dts: marvell: add DTS for Turris Mox dt-bindings: marvell: document Turris Mox compatible arm64: dts: marvell: armada-37xx: add SPI CS1 pinctrl arm64: dts: marvell: Add cpu clock node on Armada 7K/8K arm64: dts: marvell: Convert 7k/8k usb-phy properties to phy-supply arm64: dts: marvell: Add 7k/8k PHYs in PCIe nodes arm64: dts: marvell: Add 7k/8k PHYs in USB3 nodes arm64: dts: marvell: Add 7k/8k per-port PHYs in SATA nodes arm64: dts: marvell: Add CP110 COMPHY clocks arm64: dts: marvell: armada-37xx: add mailbox node dt-bindings: gpio: Document GPIOs via Moxtet bus drivers: gpio: Add support for GPIOs over Moxtet bus bus: moxtet: Add sysfs and debugfs documentation dt-bindings: bus: Document moxtet bus binding bus: Add support for Moxtet bus reset: Add support for resets provided by SCMI firmware: arm_scmi: Add RESET protocol in SCMI v2.0 dt-bindings: arm: Extend SCMI to support new reset protocol firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels ... Link: https://lore.kernel.org/r/87h85two0r.fsf@FE-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'ti-k3-soc-for-v5.4' of ↵Arnd Bergmann9-45/+295
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux into arm/late Texas Instruments K3 SoC family changes for 5.4 - Typo fixes for gic-its unit addresses for both am654 and j721e - HW spinlock nodes added for both am654 and j721e - GPIO support for j721e - power-domain cells update for both am654 / j721e for exclusive only access * tag 'ti-k3-soc-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux: arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address arm64: dts: ti: k3-j721e-main: Add hwspinlock node arm64: dts: ti: k3-am65-main: Add hwspinlock node arm64: dts: k3-j721e: Add gpio-keys on common processor board dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio modules arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain arm64: dts: ti: k3-j721e: Add gpio nodes in main domain arm64: dts: ti: k3-j721e: Update the power domain cells arm64: dts: ti: k3-am654: Update the power domain cells soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access firmware: ti_sci: Allow for device shared and exclusive requests Link: https://lore.kernel.org/r/b838d666-ab3b-7d41-67d4-09d606c732da@ti.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'omap-for-v5.4/ti-sysc-sgx-signed' of ↵Arnd Bergmann7-54/+115
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late SoC glue layer changes for SGX on omap variants for v5.4 For a while we've had omap4 sgx glue layer defined in dts and probed with ti-sysc driver. This allows idling the sgx module for PM, and removes the need for custom platform glue layer code for any further driver changes. We first drop the unused legacy platform data for omap4 sgx. Then for omap5, we need add the missing clkctrl clock data so we can configure sgx. And we configure sgx for omap34xx, omap36xx and am3517. For am335x, we still have a dependency for rstctrl reset driver changes, so that will be added later on. Note that this branch is based on earlier ti-sysc branch for omap36xx glue layer quirk handling. * tag 'omap-for-v5.4/ti-sysc-sgx-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx ARM: dts: Configure interconnect target module for omap3 sgx ARM: dts: Configure sgx for omap5 clk: ti: add clkctrl data omap5 sgx ARM: OMAP2+: Drop legacy platform data for omap4 gpu Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-4 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'omap-for-v5.4/ti-sysc-drop-pdata-take2-signed' of ↵Arnd Bergmann12-724/+36
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/late Drop legacy platform data omap variants for v5.4 We can now drop more platform data in favor of dts data for most devices like cpsw, gpio, i2c, mmc, uart and watchdog. In general we can do this by dropping legacy "ti,hwmods" custom dts property, and the platform data assuming the related dts data is correct. This is best done as single patch as otherwise we'd have to revert two patches in case of any unexpected issues, and we're just removing data. Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks properly in dts though in the first patch. For omap4 i2c, we've already dropped the platform data earlier, but have been still allocting it dynamically based on the dts data based on the "ti,hwmods" property, but that is no longer needed. For d2d, we are missing the dts data, so we first add it and then drop the platform data. For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi. We've already dropped platform data earlier for gpio, i2c, mmc, and uart so we just need to drop "ti,hwmods" property for those. Note that this branch is based on earlier ti-sysc-fixes branch. * tag 'omap-for-v5.4/ti-sysc-drop-pdata-take2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: dts: Drop legacy custom hwmods property for dra7 gpio ARM: dts: Drop legacy custom hwmods property for dra7 mmc ARM: dts: Drop legacy custom hwmods property for dra7 i2c ARM: dts: Drop legacy custom hwmods property for dra7 uart ARM: OMAP2+: Drop legacy platform data for dra7 mcasp ARM: OMAP2+: Drop legacy platform data for dra7 mcspi ARM: OMAP2+: Drop legacy platform data for omap4 d2d ARM: dts: Configure d2d dts data for omap4 ARM: OMAP2+: Drop legacy watchdog platform data for omap4 ARM: dts: Drop custom hwmod property for omap4 i2c ARM: OMAP2+: Drop legacy platform data for cpsw on dra7 ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4 ARM: dts: Add fck for cpsw mdio for omap variants Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.com-3 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04arm64: defconfig: Enable Qualcomm QUSB2 PHYLee Jones1-0/+1
Tested on the Lenovo Yoga C630 where this patch enables USB. Without it USB devices are not enumerated. Link: https://lore.kernel.org/r/20190903192625.14775-3-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04arm64: defconfig: Enable the EFI FramebufferLee Jones1-0/+1
Tested on the Lenovo Yoga C630 where this patch enables the framebuffer (screen/monitor). Without it the device appears not to boot. Link: https://lore.kernel.org/r/20190903192625.14775-2-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04arm64: defconfig: Enable Qualcomm GENI based I2C controllerLee Jones1-0/+1
Tested on the Lenovo Yoga C630 where this patch enables the keyboard, touchpad and touchscreen. Link: https://lore.kernel.org/r/20190903192625.14775-1-lee.jones@linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'arm-soc/for-5.4/devicetree' of ↵Arnd Bergmann17-26/+144
https://github.com/Broadcom/stblinux into arm/dt This pull request contains Broadcom ARM-based SoCs Device Tree updates for 5.4, please pull the following: - Stefan does a bunch of preparatory work for supporting the Raspberry Pi 4in the next merge window correct register ranges (SPI, I2C, UART), define memory, HDMI and MMC properties at the board level * tag 'arm-soc/for-5.4/devicetree' of https://github.com/Broadcom/stblinux: ARM: dts: bcm283x: Enable HDMI at board level ARM: dts: bcm283x: Define memory at board level ARM: dts: bcm283x: Define MMC interfaces at board level ARM: bcm283x: Reduce register ranges for UART, SPI and I2C
2019-09-04Merge tag 'qcom-defconfig-for-5.4' of ↵Arnd Bergmann2-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM Based defconfig Updates for v5.4 * Add DRM_MSM to ARCH_QCOM defconfigs * tag 'qcom-defconfig-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: ARM: multi_v7_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM ARM: qcom_defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM
2019-09-04Merge tag 'qcom-arm64-for-5.4' of ↵Arnd Bergmann22-209/+3725
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt Qualcomm ARM64 Updates for v5.4 * Add Lenovo Miix 630, HP Envy x2, and Asus Novago TP370QL support * Assorted cleanups for SDM845 nodes * Add video nodes, cpu coefficients, adsp, csdp, and fastrpc nodes for SDM845 * Add coresight for MSM8996, SDM845, and MSM8998 * Misc cleanups on QCS404 and PMS405 * Update memory map for QCS404 * Add wifi rails, update WCSS clocks, and add ADS unit names on QCS404 * Add Longcheer and Samsung Galaxy A3U/A5U support * Add initial support for SM8150 and PM8150 * tag 'qcom-arm64-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (39 commits) arm64: dts: sdm845: Add parent clock for rpmhcc arm64: dts: qcom: sm8150: Add apps shared nodes arm64: dts: qcom: sm8150: Add reserved-memory regions arm64: dts: qcom: sm8150-mtp: Add regulators arm64: dts: qcom: sm8150-mtp: Add base dts file arm64: dts: qcom: pm8150l: Add base dts file arm64: dts: qcom: pm8150b: Add base dts file arm64: dts: qcom: pm8150: Add base dts file arm64: dts: qcom: sm8150: Add base dts file arm64: sdm845: add adsp and cdsp fastrpc nodes arm64: dts: sdm845: Add dynamic CPU power coefficients arm64: dts: qcom: qcs404: Update memory map to v3 arm64: dts: qcom: qcs404-evb: Mark WCSS clocks protected arm64: dts: qcom: Add device tree for Longcheer L8150 arm64: dts: qcom: Add device tree for Samsung Galaxy A3U/A5U dt-bindings: qcom: Document bindings for new MSM8916 devices dt-bindings: vendor-prefixes: Add Longcheer Technology Co., Ltd. arm64: dts: qcom: msm8996: Add Venus video codec DT node arm64: dts: qcom: Extend AOSS QMP node arm64: dts: qcom: msm8996: Add Coresight support ...
2019-09-04Merge tag 'qcom-arm64-defconfig-for-5.4' of ↵Arnd Bergmann1-0/+5
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig Qualcomm ARM64 Based defconfig Updates for v5.4 * Enable Qualcomm MSM8916 clock drivers * Add DRM_MSM to ARCH_QCOM defconfigs * Enable Qualcomm SM8150 clock and pinctrl drivers * tag 'qcom-arm64-defconfig-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: arm64: defconfig: Enable CPU clock drivers for Qualcomm msm8916 arm64: defconfig: Add DRM_MSM to defconfigs with ARCH_QCOM arm64: defconfig: Enable SM8150 GCC and pinctrl driver
2019-09-04Merge tag 'davinci-for-v5.4/dt' of ↵Arnd Bergmann1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/dt Contains a patch to switch to more generic compatible for SPI NOR. This helps SPI NOR to work on newer board variants. * tag 'davinci-for-v5.4/dt' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: dts: da850-evm: Use generic jedec, spi-nor for flash Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'davinci-for-v5.4/fbdev' of ↵Arnd Bergmann1-24/+66
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/drivers This converts the da8xx fbdev driver to use GPIO backlight device and regulator devices. This will finally help get rid of legacy GPIO API calls and simplify DaVinci GPIO driver. * tag 'davinci-for-v5.4/fbdev' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: fbdev: da8xx: use resource management for dma fbdev: da8xx-fb: drop a redundant if fbdev: da8xx-fb: use devm_platform_ioremap_resource() fbdev: da8xx: remove panel_power_ctrl() callback from platform data ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc fbdev: da8xx: add support for a regulator ARM: davinci: da850-evm: model the backlight GPIO as an actual device Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)Masahiro Yamada2-3/+5
Kbuild provides per-file compiler flag addition/removal: CFLAGS_<basetarget>.o CFLAGS_REMOVE_<basetarget>.o AFLAGS_<basetarget>.o AFLAGS_REMOVE_<basetarget>.o CPPFLAGS_<basetarget>.lds HOSTCFLAGS_<basetarget>.o HOSTCXXFLAGS_<basetarget>.o The <basetarget> is the filename of the target with its directory and suffix stripped. This syntax comes into a trouble when two files with the same basename appear in one Makefile, for example: obj-y += foo.o obj-y += dir/foo.o CFLAGS_foo.o := <some-flags> Here, the <some-flags> applies to both foo.o and dir/foo.o The real world problem is: scripts/kconfig/util.c scripts/kconfig/lxdialog/util.c Both files are compiled into scripts/kconfig/mconf, but only the latter should be given with the ncurses flags. It is more sensible to use the relative path to the Makefile, like this: obj-y += foo.o CFLAGS_foo.o := <some-flags> obj-y += dir/foo.o CFLAGS_dir/foo.o := <other-flags> At first, I attempted to replace $(basetarget) with $*. The $* variable is replaced with the stem ('%') part in a pattern rule. This works with most of cases, but does not for explicit rules. For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own explicit rules, so $* will be empty, resulting in ignoring the per-file AFLAGS. I introduced a new variable, target-stem, which can be used also from explicit rules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Marc Zyngier <maz@kernel.org>
2019-09-04kbuild: add $(BASH) to run scripts with bash-extensionMasahiro Yamada3-3/+3
CONFIG_SHELL falls back to sh when bash is not installed on the system, but nobody is testing such a case since bash is usually installed. So, shell scripts invoked by CONFIG_SHELL are only tested with bash. It makes it difficult to test whether the hashbang #!/bin/sh is real. For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is false. (I fixed it up) Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may not always be set to bash. Probably, the right thing to do is to introduce BASH, which is bash by default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL) with $(BASH) for bash scripts. If somebody tries to add bash-extension to a #!/bin/sh script, it will be caught in testing because /bin/sh is a symlink to dash on some major distributions. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-09-04KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regsThomas Huth2-0/+10
If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this clearly indicates that something went wrong in the KVM userspace application. The x86 variant of KVM already contains a check for bad bits, so let's do the same on s390x now, too. Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/lkml/20190904085200.29021-2-thuth@redhat.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2019-09-04Merge tag 'davinci-for-v5.4/soc' of ↵Arnd Bergmann10-110/+95
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into arm/soc This converts all DaVinci SoCs except DM365 to use new clocksource driver. DM365 conversion is still under debug and will be part of a future pull request. * tag 'davinci-for-v5.4/soc' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci: ARM: davinci: dm646x: Fix a typo in the comment ARM: davinci: dm646x: switch to using the clocksource driver ARM: davinci: dm644x: switch to using the clocksource driver ARM: davinci: dm355: switch to using the clocksource driver ARM: davinci: move timer definitions to davinci.h ARM: davinci: da830: switch to using the clocksource driver ARM: davinci: da850: switch to using the clocksource driver ARM: davinci: WARN_ON() if clk_get() fails ARM: davinci: enable the clocksource driver for DT mode Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'arm-soc/for-5.4/defconfig-arm64' of ↵Arnd Bergmann1-0/+2
https://github.com/Broadcom/stblinux into arm/defconfig This pull request contains Broadcom ARM64-based SoCs defconfig updates for 5.4, please pull the following: - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file * tag 'arm-soc/for-5.4/defconfig-arm64' of https://github.com/Broadcom/stblinux: arm64: defconfig: enable cpufreq support for RPi3
2019-09-04Merge tag 'arm-soc/for-5.4/defconfig' of ↵Arnd Bergmann2-0/+11
https://github.com/Broadcom/stblinux into arm/defconfig This pull request contains Broadcom ARM-based SoCs defconfig updates for 5.4, please pull the following: - Nicolas enables the Raspberry Pi CPUFREQ driver in both bcm2835_defconfig and multi_v7_defconfig * tag 'arm-soc/for-5.4/defconfig' of https://github.com/Broadcom/stblinux: ARM: defconfig: enable cpufreq driver for RPi
2019-09-04Merge tag 'bitmain-soc-5.4' of ↵Arnd Bergmann1-2/+13
git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-bitmain into arm/dt Bitmain SoC changes for v5.4: Most of the basic infrastructure is completed for BM1880 SoC except common clock support. We are still couple of patchset away from booting a distro from eMMC/SD with mainline. Below are the changes for this cycle: - Added Reset controller support to BM1880 SoC based on reset-simple driver. - Modified pinctrl memory map for BM1880 SoC. The initial pinctrl support included the PWM registers as a part of the pinctrl memory map. But this turned out to be useless as PWM registers are not handling any pin muxing at all. So removed the PWM registers from pinctrl memory map. * tag 'bitmain-soc-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/linux-bitmain: arm64: dts: bitmain: Modify pin controller memory map arm64: dts: bitmain: Add reset controller support for BM1880 SoC Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'renesas-fixes-for-v5.3' of ↵Arnd Bergmann1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into arm/fixes Renesas ARM Based SoC Fixes for v5.3 * R-Car D3 (r8a77995) based Draak Board - Correct backlight regulator name in device tree * tag 'renesas-fixes-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04powerpc/tm: Fix restoring FP/VMX facility incorrectly on interruptsGustavo Romero1-16/+2
When in userspace and MSR FP=0 the hardware FP state is unrelated to the current process. This is extended for transactions where if tbegin is run with FP=0, the hardware checkpoint FP state will also be unrelated to the current process. Due to this, we need to ensure this hardware checkpoint is updated with the correct state before we enable FP for this process. Unfortunately we get this wrong when returning to a process from a hardware interrupt. A process that starts a transaction with FP=0 can take an interrupt. When the kernel returns back to that process, we change to FP=1 but with hardware checkpoint FP state not updated. If this transaction is then rolled back, the FP registers now contain the wrong state. The process looks like this: Userspace: Kernel Start userspace with MSR FP=0 TM=1 < ----- ... tbegin bne Hardware interrupt ---- > <do_IRQ...> .... ret_from_except restore_math() /* sees FP=0 */ restore_fp() tm_active_with_fp() /* sees FP=1 (Incorrect) */ load_fp_state() FP = 0 -> 1 < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk When returning from the hardware exception, tm_active_with_fp() is incorrectly making restore_fp() call load_fp_state() which is setting FP=1. The fix is to remove tm_active_with_fp(). tm_active_with_fp() is attempting to handle the case where FP state has been changed inside a transaction. In this case the checkpointed and transactional FP state is different and hence we must restore the FP state (ie. we can't do lazy FP restore inside a transaction that's used FP). It's safe to remove tm_active_with_fp() as this case is handled by restore_tm_state(). restore_tm_state() detects if FP has been using inside a transaction and will set load_fp and call restore_math() to ensure the FP state (checkpoint and transaction) is restored. This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. Similarly for VMX. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c This fixes CVE-2019-15031. Fixes: a7771176b439 ("powerpc: Don't enable FP/Altivec if not checkpointed") Cc: stable@vger.kernel.org # 4.15+ Signed-off-by: Gustavo Romero <gromero@linux.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
2019-09-04powerpc/tm: Fix FP/VMX unavailable exceptions inside a transactionGustavo Romero1-1/+2
When we take an FP unavailable exception in a transaction we have to account for the hardware FP TM checkpointed registers being incorrect. In this case for this process we know the current and checkpointed FP registers must be the same (since FP wasn't used inside the transaction) hence in the thread_struct we copy the current FP registers to the checkpointed ones. This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr to determine if FP was on when in userspace. thread->ckpt_regs.msr represents the state of the MSR when exiting userspace. This is setup by check_if_tm_restore_required(). Unfortunatley there is an optimisation in giveup_all() which returns early if tsk->thread.regs->msr (via local variable `usermsr`) has FP=VEC=VSX=SPE=0. This optimisation means that check_if_tm_restore_required() is not called and hence thread->ckpt_regs.msr is not updated and will contain an old value. This can happen if due to load_fp=255 we start a userspace process with MSR FP=1 and then we are context switched out. In this case thread->ckpt_regs.msr will contain FP=1. If that same process is then context switched in and load_fp overflows, MSR will have FP=0. If that process now enters a transaction and does an FP instruction, the FP unavailable will not update thread->ckpt_regs.msr (the bug) and MSR FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() will then not perform the required memcpy and the checkpointed FP regs in the thread struct will contain the wrong values. The code path for this happening is: Userspace: Kernel Start userspace with MSR FP/VEC/VSX/SPE=0 TM=1 < ----- ... tbegin bne fp instruction FP unavailable ---- > fp_unavailable_tm() tm_reclaim_current() tm_reclaim_thread() giveup_all() return early since FP/VMX/VSX=0 /* ckpt MSR not updated (Incorrect) */ tm_reclaim() /* thread_struct ckpt FP regs contain junk (OK) */ /* Sees ckpt MSR FP=1 (Incorrect) */ no memcpy() performed /* thread_struct ckpt FP regs not fixed (Incorrect) */ tm_recheckpoint() /* Put junk in hardware checkpoint FP regs */ .... < ----- Return to userspace with MSR TM=1 FP=1 with junk in the FP TM checkpoint TM rollback reads FP junk This is a data integrity problem for the current process as the FP registers are corrupted. It's also a security problem as the FP registers from one process may be leaked to another. This patch moves up check_if_tm_restore_required() in giveup_all() to ensure thread->ckpt_regs.msr is updated correctly. A simple testcase to replicate this will be posted to tools/testing/selftests/powerpc/tm/tm-poison.c Similarly for VMX. This fixes CVE-2019-15030. Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption") Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
2019-09-04arm64: remove __iounmapChristoph Hellwig2-4/+3
No need to indirect iounmap for arm64. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Will Deacon <will@kernel.org>
2019-09-04arm: remove wrappers for the generic dma remap helpersChristoph Hellwig1-27/+5
Remove a few tiny wrappers around the generic dma remap code. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: introduce a dma_common_find_pages helperChristoph Hellwig1-6/+1
A helper to find the backing page array based on a virtual address. This also ensures we do the same vm_flags check everywhere instead of slightly different or missing ones in a few places. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: always use VM_DMA_COHERENT for generic DMA remapChristoph Hellwig2-8/+6
Currently the generic dma remap allocator gets a vm_flags passed by the caller that is a little confusing. We just introduced a generic vmalloc-level flag to identify the dma coherent allocations, so use that everywhere and remove the now pointless argument. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04vmalloc: lift the arm flag for coherent mappings to common codeChristoph Hellwig2-18/+7
The arm architecture had a VM_ARM_DMA_CONSISTENT flag to mark DMA coherent remapping for a while. Lift this flag to common code so that we can use it generically. We also check it in the only place VM_USERMAP is directly check so that we can entirely replace that flag as well (although I'm not even sure why we'd want to allow remapping DMA appings, but I'd rather not change behavior). Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: provide a better default ->get_required_maskChristoph Hellwig3-7/+4
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits of IOVA space, and the generic direct mapping code already provides its own routines that is intelligent based on the amount of memory actually present. Wire up the dma-direct routine for the ARM direct mapping code as well, and otherwise default to the constant 32-bit mask. This way we only need to override it for the occasional odd IOMMU that requires 64-bit IOVA support, or IOMMU drivers that are more efficient if they can fall back to the direct mapping. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAPChristoph Hellwig6-8/+0
CONFIG_ARCH_NO_COHERENT_DMA_MMAP is now functionally identical to !CONFIG_MMU, so remove the separate symbol. The only difference is that arm did not set it for !CONFIG_MMU, but arm uses a separate dma mapping implementation including its own mmap method, which is handled by moving the CONFIG_MMU check in dma_can_mmap so that is only applies to the dma-direct case, just as the other ifdefs for it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
2019-09-04parisc: don't set ARCH_NO_COHERENT_DMA_MMAPChristoph Hellwig1-1/+0
parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT caches, which means exporting normally cachable memory to userspace is relatively dangrous due to cache aliasing. But normally cachable memory is only allocated by dma_alloc_coherent on parisc when using the sba_iommu or ccio_iommu drivers, so just remove the .mmap implementation for them so that we don't have to set ARCH_NO_COHERENT_DMA_MMAP, which I plan to get rid of. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04arm-nommu: call dma_mmap_from_dev_coherent directlyChristoph Hellwig1-2/+3
There is no need to go through dma_common_mmap for the arm-nommu dma mmap implementation as the only possible memory not handled above could be that from the per-device coherent pool. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: explicitly wire up ->mmap and ->get_sgtableChristoph Hellwig10-0/+22
While the default ->mmap and ->get_sgtable implementations work for the majority of our dma_map_ops impementations they are inherently safe for others that don't use the page allocator or CMA and/or use their own way of remapping not covered by the common code. So remove the defaults if these methods are not wired up, but instead wire up the default implementations for all safe instances. Fixes: e1c7e324539a ("dma-mapping: always provide the dma_map_ops based implementation") Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04dma-mapping: move the dma_get_sgtable API comments from arm to common codeChristoph Hellwig1-11/+0
The comments are spot on and should be near the central API, not just near a single implementation. Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-04kbuild,arc: add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 for ARCMasahiro Yamada17-8/+16
arch/arc/Makefile overrides -O2 with -O3. This is the only user of ARCH_CFLAGS. There is no user of ARCH_CPPFLAGS or ARCH_AFLAGS. My plan is to remove ARCH_{CPP,A,C}FLAGS after refactoring the ARC Makefile. Currently, ARC has no way to enable -Wmaybe-uninitialized because both -O3 and -Os disable it. Enabling it will be useful for compile-testing. This commit allows allmodconfig (, which defaults to -O2) to enable it. Add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3=y to all the defconfig files in arch/arc/configs/ in order to keep the current config settings. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Vineet Gupta <vgupta@synopsys.com>
2019-09-04Merge tag 'amlogic-dt64-2.1' of ↵Arnd Bergmann28-440/+724
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/dt arm64: dts: Amlogic updates for v5.4 (round 2) - new board: Khadas VIM3L (SM1/S905D3 SoC) - support power domains on G12[AB] and SM1 SoCs - DT binding fixups based on YAML schema - add a bunch of remote control keymap - enable DVFS on SM1/SEI610 board * tag 'amlogic-dt64-2.1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: (44 commits) arm64: dts: meson-sm1-sei610: add stdout-path property back arm64: dts: meson-sm1-sei610: enable DVFS arm64: dts: khadas-vim3: add support for the SM1 based VIM3L dt-bindings: arm: amlogic: add Amlogic SM1 based Khadas VIM3L bindings arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi arm64: dts: meson: g12a: add reset to tdm formatters arm64: dts: meson: g12a: audio clock controller provides resets arm64: dts: meson-sm1-sei610: enable DVFS arm64: dts: meson-gxm-khadas-vim2: use rc-khadas keymap arm64: dts: meson-gxl-s905w-tx3-mini: add rc-tx3mini keymap arm64: dts: meson-gxl-s905x-khadas-vim: use rc-khadas keymap arm64: dts: meson-gxbb-wetek-play2: add rc-wetek-play2 keymap arm64: dts: meson-gxbb-wetek-hub: add rc-wetek-hub keymap arm64: dts: meson-g12a-x96-max: add rc-x96max keymap arm64: dts: meson-g12b-odroid-n2: add rc-odroid keymap arm64: dts: meson-sm1-sei610: add USB support arm64: dts: meson-sm1-sei610: add HDMI display support arm64: dts: meson-g12: add Everything-Else power domain controller arm64: dts: meson: fix boards regulators states format arm64: dts: meson-gxbb-p201: fix snps, reset-delays-us format ... Link: https://patchwork.kernel.org/patch/11122331/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'renesas-arm-soc-for-v5.4-tag1' of ↵Arnd Bergmann2-2/+24
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/soc Renesas ARM SoC updates for v5.4 - Low-level debugging support for RZ/A2M. * tag 'renesas-arm-soc-for-v5.4-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: ARM: debug-ll: Add support for r7s9210 Link: https://lore.kernel.org/r/20190823123643.18799-3-geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04Merge tag 'zynq-soc-for-v5.4' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann2-2/+4
arm/soc ARM: Xilinx Zynq SoC patches for v5.4 - Add support for SMP in thumb mode - Fix SMP trampoline code when FORTIFY_SOURCE is enabled * tag 'zynq-soc-for-v5.4' of https://github.com/Xilinx/linux-xlnx: ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up ARM: zynq: Support smp in thumb mode Link: https://lore.kernel.org/r/8e00ba70-9403-4bf7-2870-a94758e37346@monstr.eu Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-01 16:46:28 +0300