summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2020-01-09ARM: dts: imx7: Fix Toradex Colibri iMX7S 256MB NAND flash supportMarcel Ziswiler
Turns out when introducing the eMMC version the gpmi node required for NAND flash support got enabled exclusively on Colibri iMX7D 512MB. Fixes: f928a4a377e4 ("ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support") Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: imx8mn: Memory node should be in board DTAnson Huang
Memory address/size depends on board design, so memory node should be in board DT. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: imx8mm: Memory node should be in board DTAnson Huang
Memory address/size depends on board design, so memory node should be in board DT. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: imx: only select ARM_ERRATA_814220 for ARMv7-AArnd Bergmann
i.MX7D is supported for either the v7-A or the v7-M cores, but the latter causes a warning: WARNING: unmet direct dependencies detected for ARM_ERRATA_814220 Depends on [n]: CPU_V7 [=n] Selected by [y]: - SOC_IMX7D [=y] && ARCH_MXC [=y] && (ARCH_MULTI_V7 [=n] || ARM_SINGLE_ARMV7M [=y]) Make the select statement conditional. Fixes: 4562fa4c86c9 ("ARM: imx: Enable ARM_ERRATA_814220 for i.MX6UL and i.MX7D") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6ul-14x14-evk: Pass the "broken-cd" propertyFabio Estevam
imx6ul-14x14-evk does not have a GPIO dedicated for reading the card detect pin on the eSDHC2 micro-SD port. Pass the "broken-cd" property to describe the absence of the card detect GPIO so that polling must be used. According to Documentation/devicetree/bindings/mmc/mmc-controller.yaml: broken-cd: $ref: /schemas/types.yaml#/definitions/flag description: There is no card detection available; polling must be used. Even though no error is oberved in the kernel, the lack of the 'broken-cd' property caused the micro-SD to not be detected in U-Boot, so let's improve the device tree description to make it more accurate. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: imx8mn: add crypto nodeHoria Geantă
Add node for CAAM - Cryptographic Acceleration and Assurance Module. Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Tested-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sl-tolino-shine3: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sll-evk: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 96a9169cf621 ("ARM: dts: imx6sll-evk: Assign corresponding power supply for vdd3p0") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sl-evk: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 3feea8805d6f ("ARM: dts: imx6sl-evk: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6sx-sdb: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 37a4bdead109 ("ARM: dts: imx6sx-sdb: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6qdl-sabresd: Remove incorrect power supply assignmentAnson Huang
The vdd3p0 LDO's input should be from external USB VBUS directly, NOT PMIC's power supply, the vdd3p0 LDO's target output voltage can be controlled by SW, and it requires input voltage to be high enough, with incorrect power supply assigned, if the power supply's voltage is lower than the LDO target output voltage, it will return fail and skip the LDO voltage adjustment, so remove the power supply assignment for vdd3p0 to avoid such scenario. Fixes: 93385546ba36 ("ARM: dts: imx6qdl-sabresd: Assign corresponding power supply for LDOs") Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx7d-pico: Add LCD supportFabio Estevam
Add support for the VXT VL050-8048NT-C01 panel connected through the 24 bit parallel LCDIF interface. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Joris Offouga <offougajoris@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: imx8mq-hummingboard-pulse: add eeprom descriptionBaruch Siach
Add DT node for the eeprom data storage on SolidRun Hummingboard Pulse carrier board. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: imx8mq-sr-som: add eeprom descriptionBaruch Siach
Add DT node for the eeprom data storage on SolidRun i.MX8M SOM. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DLJagan Teki
The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on the 1.5 version of the i.Core MX6 cpu module. The 1.5 version differs from the original one for a few details, including the ethernet PHY interface clock provider. With this commit, the ethernet interface works properly: SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver While before using the 1.5 version, ethernet failed to startup do to un-clocked PHY interface: fec 2188000.ethernet eth0: could not attach to PHY Similar fix has merged for i.Core MX6Q but missed to update for DL. Fixes: a8039f2dd089 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support") Cc: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6qdl-icore: Add fec phy-handleMichael Trimarchi
LAN8720 needs a reset of every clock enable. The reset needs to be done at device level, due the flag PHY_RST_AFTER_CLK_EN. So, add phy-handle by creating mdio child node inside fec. This will eventually move the phy-reset-gpio which is defined in fec node. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6qdl-icore-1.5: Remove duplicate phy reset methodsMichael Trimarchi
Engicam i.CoreM6 1.5 Quad/Dual MIPI dtsi is reusing fec node from Engicam i.CoreM6 dtsi but have sampe copy of phy-reset-gpio and phy-mode properties. So, drop this phy reset methods from imx6qdl-icore-1.5 dsti file. Cc: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx7: Unify temp-grade and speed-grade nodesFabio Estevam
The following warning is seen when building with W=1: arch/arm/boot/dts/imx7s.dtsi:551.39-553.7: Warning (unique_unit_address): /soc/aips-bus@30000000/ocotp-ctrl@30350000/temp-grade@10: duplicate unit-address (also used in node /soc/aips-bus@30000000/ocotp-ctrl@30350000/speed-grade@10) Since temp-grade and speed-grade point to the same node, replace them by a single one to avoid the duplicate unit-address warning. Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: ls208xa: Update qspi node properties for LS2088ARDBKuldeep Singh
LS2088ADB has one spansion flash s25fs512s of size 64M. Add qspi dts entry for the board using compatibles as "jedec,spi-nor" to probe flash successfully. Also, align properties with other board dts properties. Use dt-bindings constants in interrupts instead of using numbers. Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09ARM: dts: imx6: phycore-som: add pmic onkey deviceMarco Felsch
Without the onkey device it isn't possible to power off the system using the X_PMIC_nONKEY signal which is routed to the SoM pin header. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09arm64: dts: freescale: Add devicetree support for Thor96 boardManivannan Sadhasivam
Add devicetree support for Thor96 board from Einfochips. This board is one of the 96Boards Consumer Edition platform powered by the NXP i.MX8MQ SoC. Following are the features supported currently: 1. uSD 2. WiFi/BT 3. Ethernet 4. EEPROM (M24256) 5. NOR Flash (W25Q256JW) 6. 2xUSB3.0 ports and 1xUSB2.0 port at HS expansion More information about this board can be found in Arrow website: https://www.arrow.com/en/products/i.imx8-thor96/arrow-development-tools Link to 96Boards CE Specification: https://linaro.co/ce-specification Signed-off-by: Darshak Patel <darshak.patel@einfochips.com> [Mani: cleaned up for upstream] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-01-09crypto: remove propagation of CRYPTO_TFM_RES_* flagsEric Biggers
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the ->setkey() functions provide more information about errors. But these flags weren't actually being used or tested, and in many cases they weren't being set correctly anyway. So they've now been removed. Also, if someone ever actually needs to start better distinguishing ->setkey() errors (which is somewhat unlikely, as this has been unneeded for a long time), we'd be much better off just defining different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that propagates these flags around. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-01-09crypto: remove CRYPTO_TFM_RES_BAD_KEY_LENEric Biggers
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-01-09arm64: dts: rockchip: Enable mp8859 regulator on rk3399-roc-pcMarkus Reichl
The rk3399-roc-pc uses a MP8859 DC/DC converter for 12V supply. This supplies 5V only in default state after booting. Now we can control the output voltage via I2C interface. Add a node for the driver to reach 12V. Signed-off-by: Markus Reichl <m.reichl@fivetechno.de> Link: https://lore.kernel.org/r/20200106211633.2882-6-m.reichl@fivetechno.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-09ARM: dts: rockchip: Use ABI name for recovery mode pin on veyron fievel/tigerMatthias Kaehlcke
The recovery mode pin is currently named 'REC_MODE_L', which is how the signal is called in the schematics. The Chrome OS ABI requires the pin to be named 'RECOVERY_SW_L', which is also how it is called on all other veyron devices. Rename the pin to match the ABI. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200108092908.1.I3afd3535b65460e79f3976e9ebfa392a0dd75e01@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-01-09Merge tag 'sh-pfc-for-v5.6-tag1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: sh-pfc: Updates for v5.5 - Split R-Car H3 support in two independent drivers, - Miscellaneous fixes and cleanups.
2020-01-08arm64: dts: marvell: clearfog-gt-8k: fix switch cpu port nodeBaruch Siach
Explicitly set the switch cpu (upstream) port phy-mode and managed properties. This fixes the Marvell 88E6141 switch serdes configuration with the recently enabled phylink layer. Fixes: a6120833272c ("arm64: dts: add support for SolidRun Clearfog GT 8K") Reported-by: Denis Odintsov <d.odintsov@traviangames.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-01-08ARM: dts: exynos: Enable FIMD node and add proper panel node to Tiny4412Yangtao Li
Enable fimd device node which is a display controller, and add panel node required by it. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-01-08ARM: dts: meson8b: use the actual frequency for the GPU's 364MHz OPPMartin Blumenstingl
The clock setup on Meson8 cannot achieve a Mali frequency of exactly 182.15MHz. The vendor driver uses "FCLK_DIV7 / 1" for this frequency, which translates to 2550MHz / 7 / 1 = 364285714Hz. Update the GPU operating point to that specific frequency to not confuse myself when comparing the frequency from the .dts with the actual clock rate on the system. Fixes: c3ea80b6138cae ("ARM: dts: meson8b: add the Mali-450 MP2 GPU") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2020-01-08ARM: dts: meson8: use the actual frequency for the GPU's 182.1MHz OPPMartin Blumenstingl
The clock setup on Meson8 cannot achieve a Mali frequency of exactly 182.15MHz. The vendor driver uses "FCLK_DIV7 / 2" for this frequency, which translates to 2550MHz / 7 / 2 = 182142857Hz. Update the GPU operating point to that specific frequency to not confuse myself when comparing the frequency from the .dts with the actual clock rate on the system. Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2020-01-08ARM: dts: meson8b: fix the clock controller compatible stringMartin Blumenstingl
The Meson8b clock controller is an evolution of the Meson8 clock controller. The clock controller on Meson8b contains two identical mali clock trees for glitch-free rate switching. Use the correct compatible string to make use of the glitch free mux. Fixes: b6db3936f2833c ("ARM: dts: meson: switch the clock controller to the HHI register area") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2020-01-08arm64: dts: meson: add audio fifo depthsJerome Brunet
Add the property describing the depth of the audio fifo on the axg, g12a and sm1 SoC family Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2020-01-08x86: Remove force_iret()Brian Gerst
force_iret() was originally intended to prevent the return to user mode with the SYSRET or SYSEXIT instructions, in cases where the register state could have been changed to be incompatible with those instructions. The entry code has been significantly reworked since then, and register state is validated before SYSRET or SYSEXIT are used. force_iret() no longer serves its original purpose and can be eliminated. Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://lkml.kernel.org/r/20191219115812.102620-1-brgerst@gmail.com
2020-01-08Merge tag 'aspeed-5.5-devicetree-fixes' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed into arm/fixes ASPEED device tree fixes for 5.5 Fixes for some badly applied patches that went in to 5.5. There is also a fix for an incorrect i2c address. * tag 'aspeed-5.5-devicetree-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed: ARM: dts: aspeed: rainier: Fix fan fault and presence ARM: dts: aspeed: rainier: Remove duplicate i2c busses ARM: dts: aspeed: tacoma: Remove duplicate flash nodes ARM: dts: aspeed: tacoma: Remove duplicate i2c busses ARM: dts: aspeed: tacoma: Fix fsi master node ARM: dts: aspeed-g6: Fix FSI master location Link: https://lore.kernel.org/r/CACPK8XcjazgORXNZBU1ECMukXG4HA8D9VeDxiSPifDk_iB7_dw@mail.gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2020-01-08ARM: omap2plus: select RESET_CONTROLLERArnd Bergmann
With the new omap_prm driver added unconditionally, omap2 builds fail when the reset controller subsystem is disabled: drivers/soc/ti/omap_prm.o: In function `omap_prm_probe': omap_prm.c:(.text+0x2d4): undefined reference to `devm_reset_controller_register' Link: https://lore.kernel.org/r/20191216132132.3330811-1-arnd@arndb.de Fixes: 3e99cb214f03 ("soc: ti: add initial PRM driver with reset control support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2020-01-08ARM: davinci: select CONFIG_RESET_CONTROLLERArnd Bergmann
Selecting RESET_CONTROLLER is actually required, otherwise we can get a link failure in the clock driver: drivers/clk/davinci/psc.o: In function `__davinci_psc_register_clocks': psc.c:(.text+0x9a0): undefined reference to `devm_reset_controller_register' drivers/clk/davinci/psc-da850.o: In function `da850_psc0_init': psc-da850.c:(.text+0x24): undefined reference to `reset_controller_add_lookup' Link: https://lore.kernel.org/r/20191210195202.622734-1-arnd@arndb.de Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5") Cc: <stable@vger.kernel.org> # v5.4 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2020-01-08Merge tag 'tags/bcm2835-dt-next-2020-01-07' into devicetree/nextFlorian Fainelli
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2020-01-08mm: change_memory_common: add spaces for `*` operatorPan Zhang
Leaves one space before and after a binary operator both, it may be more elegant. Signed-off-by: Pan Zhang <zhangpan26@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08arm64: Remove __exception_text_start and __exception_text_end from asm/section.hPrabhakar Kushwaha
Linux commit b6e43c0e3129 ("arm64: remove __exception annotations") has removed __exception_text_start and __exception_text_end sections. So removing reference of __exception_text_start and __exception_text_end from from asm/section.h. Cc: James Morse <james.morse@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08arm64: Kconfig: Remove CONFIG_ prefix from ARM64_PSEUDO_NMI sectionJoe Perches
Remove the CONFIG_ prefix from the select statement for ARM_GIC_V3. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08arm64: armv8_deprecated: update the comments of armv8_deprecated_init()Hanjun Guo
In commit c0d8832e78cb ("arm64: Ensure the instruction emulation is ready for userspace"), armv8_deprecated_init() was promoted to core_initcall() but the comments were left unchanged, update it now. Spotted by some random reading of the code. Signed-off-by: Hanjun Guo <guohanjun@huawei.com> [will: "can guarantee" => "guarantees"] Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08arm64: kpti: Add Broadcom Brahma-B53 core to the KPTI whitelistFlorian Fainelli
Broadcom Brahma-B53 CPUs do not implement ID_AA64PFR0_EL1.CSV3 but are not susceptible to Meltdown, so add all Brahma-B53 part numbers to kpti_safe_list[]. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08Return ENODEV when the selected speculation misfeature is unsupportedAnthony Steinhauser
When the control of the selected speculation misbehavior is unsupported, the kernel should return ENODEV according to the documentation: https://www.kernel.org/doc/html/v4.17/userspace-api/spec_ctrl.html Current aarch64 implementation of SSB control sometimes returns EINVAL which is reserved for unimplemented prctl and for violations of reserved arguments. This change makes the aarch64 implementation consistent with the x86 implementation and with the documentation. Signed-off-by: Anthony Steinhauser <asteinhauser@google.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-08KVM: x86/mmu: WARN if root_hpa is invalid when handling a page faultSean Christopherson
WARN if root_hpa is invalid when handling a page fault. The check on root_hpa exists for historical reasons that no longer apply to the current KVM code base. Remove an equivalent debug-only warning in direct_page_fault(), whose existence more or less confirms that root_hpa should always be valid when handling a page fault. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: WARN on an invalid root_hpaSean Christopherson
WARN on the existing invalid root_hpa checks in __direct_map() and FNAME(fetch). The "legitimate" path that invalidated root_hpa in the middle of a page fault is long since gone, i.e. it should no longer be impossible to invalidate in the middle of a page fault[*]. The root_hpa checks were added by two related commits 989c6b34f6a94 ("KVM: MMU: handle invalid root_hpa at __direct_map") 37f6a4e237303 ("KVM: x86: handle invalid root_hpa everywhere") to fix a bug where nested_vmx_vmexit() could be called *in the middle* of a page fault. At the time, vmx_interrupt_allowed(), which was and still is used by kvm_can_do_async_pf() via ->interrupt_allowed(), directly invoked nested_vmx_vmexit() to switch from L2 to L1 to emulate a VM-Exit on a pending interrupt. Emulating the nested VM-Exit resulted in root_hpa being invalidated by kvm_mmu_reset_context() without explicitly terminating the page fault. Now that root_hpa is checked for validity by kvm_mmu_page_fault(), WARN on an invalid root_hpa to detect any flows that reset the MMU while handling a page fault. The broken vmx_interrupt_allowed() behavior has long since been fixed and resetting the MMU during a page fault should not be considered legal behavior. [*] It's actually technically possible in FNAME(page_fault)() because it calls inject_page_fault() when the guest translation is invalid, but in that case the page fault handling is immediately terminated. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: Move root_hpa validity checks to top of page fault handlerSean Christopherson
Add a check on root_hpa at the beginning of the page fault handler to consolidate several checks on root_hpa that are scattered throughout the page fault code. This is a preparatory step towards eventually removing such checks altogether, or at the very least WARNing if an invalid root is encountered. Remove only the checks that can be easily audited to confirm that root_hpa cannot be invalidated between their current location and the new check in kvm_mmu_page_fault(), and aren't currently protected by mmu_lock, i.e. keep the checks in __direct_map() and FNAME(fetch) for the time being. The root_hpa checks that are consolidate were all added by commit 37f6a4e237303 ("KVM: x86: handle invalid root_hpa everywhere") which was a follow up to a bug fix for __direct_map(), commit 989c6b34f6a94 ("KVM: MMU: handle invalid root_hpa at __direct_map") At the time, nested VMX had, in hindsight, crazy handling of nested interrupts and would trigger a nested VM-Exit in ->interrupt_allowed(), and thus unexpectedly reset the MMU in flows such as can_do_async_pf(). Now that the wonky nested VM-Exit behavior is gone, the root_hpa checks are bogus and confusing, e.g. it's not at all obvious what they actually protect against, and at first glance they appear to be broken since many of them run without holding mmu_lock. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: Move calls to thp_adjust() down a levelSean Christopherson
Move the calls to thp_adjust() down a level from the page fault handlers to the map/fetch helpers and remove the page count shuffling done in thp_adjust(). Despite holding a reference to the underlying page while processing a page fault, the page fault flows don't actually rely on holding a reference to the page when thp_adjust() is called. At that point, the fault handlers hold mmu_lock, which prevents mmu_notifier from completing any invalidations, and have verified no invalidations from mmu_notifier have occurred since the page reference was acquired (which is done prior to taking mmu_lock). The kvm_release_pfn_clean()/kvm_get_pfn() dance in thp_adjust() is a quirk that is necessitated because thp_adjust() modifies the pfn that is consumed by its caller. Because the page fault handlers call kvm_release_pfn_clean() on said pfn, thp_adjust() needs to transfer the reference to the correct pfn purely for correctness when the pfn is released. Calling thp_adjust() from __direct_map() and FNAME(fetch) means the pfn adjustment doesn't change the pfn as seen by the page fault handlers, i.e. the pfn released by the page fault handlers is the same pfn that was returned by gfn_to_pfn(). Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: Move transparent_hugepage_adjust() above __direct_map()Sean Christopherson
Move thp_adjust() above __direct_map() in preparation of calling thp_adjust() from __direct_map() and FNAME(fetch). No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: Consolidate tdp_page_fault() and nonpaging_page_fault()Sean Christopherson
Consolidate the direct MMU page fault handlers into a common helper, direct_page_fault(). Except for unique max level conditions, the tdp and nonpaging fault handlers are functionally identical. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-08KVM: x86/mmu: Rename lpage_disallowed to account_disallowed_nx_lpageSean Christopherson
Rename __direct_map()'s param that controls whether or not a disallowed NX large page should be accounted to match what it actually does. The nonpaging_page_fault() case unconditionally passes %false for the param even though it locally sets lpage_disallowed. No functional change intended. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>