summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'arm-soc-fixes-v5.13-2' of ↵Linus Torvalds2021-06-0626-113/+96
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A set of fixes that have been coming in over the last few weeks, the usual mix of fixes: - DT fixups for TI K3 - SATA drive detection fix for TI DRA7 - Power management fixes and a few build warning removals for OMAP - OP-TEE fix to use standard API for UUID exporting - DT fixes for a handful of i.MX boards And a few other smaller items" * tag 'arm-soc-fixes-v5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (29 commits) arm64: meson: select COMMON_CLK soc: amlogic: meson-clk-measure: remove redundant dev_err call in meson_msr_probe() ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_power bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cells ARM: dts: imx7d-pico: Fix the 'tuning-step' property ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' property arm64: dts: freescale: sl28: var1: fix RGMII clock and voltage arm64: dts: freescale: sl28: var4: fix RGMII clock and voltage ARM: imx: pm-imx27: Include "common.h" arm64: dts: zii-ultra: fix 12V_MAIN voltage arm64: dts: zii-ultra: remove second GEN_3V3 regulator instance arm64: dts: ls1028a: fix memory node bus: ti-sysc: Fix am335x resume hang for usb otg module ARM: OMAP2+: Fix build warning when mmc_omap is not built ARM: OMAP1: isp1301-omap: Add missing gpiod_add_lookup_table function ARM: OMAP1: Fix use of possibly uninitialized irq variable optee: use export_uuid() to copy client UUID arm64: dts: ti: k3*: Introduce reg definition for interrupt routers arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via explicit ranges ...
| * Merge tag 'ti-k3-dt-fixes-for-v5.13' of ↵Olof Johansson2021-06-0510-63/+45
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/fixes Devicetree fixes for TI K3 platforms for v5.13 merge window: These minor fixes include: * Fixups for device tree discovered during yaml conversion * Fixups for missing dma-coherent property in j7200 * Removal of camera sensor node from am65 evm dts to overlay as camera sensor boards are variable. * tag 'ti-k3-dt-fixes-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux: arm64: dts: ti: k3*: Introduce reg definition for interrupt routers arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via explicit ranges arm64: dts: ti: k3-*: Rename the TI-SCI node arm64: dts: ti: k3-am65-wakeup: Drop un-necessary properties from dmsc node arm64: dts: ti: k3-am65-wakeup: Add debug region to TI-SCI node arm64: dts: ti: k3-*: Rename the TI-SCI clocks node name arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherent arm64: dts: ti: k3-am654-base-board: remove ov5640 Link: https://lore.kernel.org/r/20210518115634.467vgpbzplal5kou@obituary Signed-off-by: Olof Johansson <olof@lixom.net>
| | * arm64: dts: ti: k3*: Introduce reg definition for interrupt routersNishanth Menon2021-05-148-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interrupt routers are memory mapped peripherals, that are organized in our dts bus hierarchy to closely represents the actual hardware behavior. However, without explicitly calling out the reg property, using 2021.03+ dt-schema package, this exposes the following problem with dtbs_check: /arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], ..... Even though we don't use interrupt router directly via memory mapped registers and have to use it via the system controller, the hardware block is memory mapped, so describe the base address in device tree. This is a valid, comprehensive description of hardware and permitted by the existing ti,sci-intr schema. Reviewed-by: Tero Kristo <kristo@kernel.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210511194821.13919-1-nm@ti.com
| | * arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via ↵Nishanth Menon2021-05-145-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | explicit ranges Instead of using empty ranges property, lets map explicitly the address range that is mapped onto the dma / navigator subsystems (navss/dmss). This is also exposed via the dtbs_check with dt-schema newer than 2021.03 version by throwing out following: arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: main-navss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], ..... This has already been correctly done for J7200, however was missed for other k3 SoCs. Fix that oversight. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20210510145429.8752-1-nm@ti.com
| | * arm64: dts: ti: k3-*: Rename the TI-SCI nodeNishanth Menon2021-05-144-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lets rename the node name of TI-SCI node to be system-controller as it is a better standardized name for the function that TI-SCI plays in the SoC. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-5-nm@ti.com
| | * arm64: dts: ti: k3-am65-wakeup: Drop un-necessary properties from dmsc nodeNishanth Menon2021-05-141-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DMSC node does'nt require any of "#address-cells", "#size-cells" or "ranges" property as the child nodes are representations of SoC's system controller itself, so align it with the bindings. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-4-nm@ti.com
| | * arm64: dts: ti: k3-am65-wakeup: Add debug region to TI-SCI nodeNishanth Menon2021-05-141-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lets add the TISCI debug region to TI-SCI region in line with TI-SCI documentation[1]. While at it, lets rename the node to indicate the address usage. [1] http://downloads.ti.com/tisci/esd/latest/4_trace/trace.html Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-3-nm@ti.com
| | * arm64: dts: ti: k3-*: Rename the TI-SCI clocks node nameNishanth Menon2021-05-144-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use clocks as the node name for the node representing TI-SCI clock nodes. This is better renamed to being clock-controller as that is a better representative of the system controller function as a clock controller for the SoC. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tero Kristo <kristo@kernel.org> Link: https://lore.kernel.org/r/20210510145033.7426-2-nm@ti.com
| | * arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherentVignesh Raghavendra2021-05-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Traffic through main NAVSS interconnect is coherent wrt ARM caches on J7200 SoC. Add missing dma-coherent property to main_navss node. Also add dma-ranges to be consistent with mcu_navss node and with AM65/J721e main_navss and mcu_navss nodes. Fixes: d361ed88455fe ("arm64: dts: ti: Add support for J7200 SoC") Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210510180601.19458-1-vigneshr@ti.com
| | * arm64: dts: ti: k3-am654-base-board: remove ov5640Tomi Valkeinen2021-05-141-31/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AM654 EVM boards are not shipped with OV5640 sensor module, it is a separate purchase. OV5640 module is also just one of the possible sensors or capture boards you can connect. However, for some reason, OV5640 has been added to the board dts file, making it cumbersome to use other sensors. Remove the OV5640 from the dts file so that it is easy to use other sensors via DT overlays. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Pratyush Yadav <p.yadav@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210423083120.73476-1-tomi.valkeinen@ideasonboard.com
| * | Merge tag 'omap-for-v5.13/fixes-pm' of ↵Olof Johansson2021-06-054-19/+11
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes PM and build warning fixes for omaps While chasing system suspend related regressions, I noticed few other issues related to PM would be good to have fixed: - UART idling does not always work for hardware autoidle features - am335x resume works only the first time unless musb module is loaded Then there are three patches for omap1 related warnings caused by the gpio changes, and one build warning fix for legacy mmc platform code when mmc is built as a loadable module. These can all be merged whenever suitable naturally. I've sent the more urgent SATA regression fix separately although it appears in this pull request too because of the branches merged. * tag 'omap-for-v5.13/fixes-pm' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_power bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act bus: ti-sysc: Fix am335x resume hang for usb otg module ARM: OMAP2+: Fix build warning when mmc_omap is not built ARM: OMAP1: isp1301-omap: Add missing gpiod_add_lookup_table function ARM: OMAP1: Fix use of possibly uninitialized irq variable Link: https://lore.kernel.org/r/pull-1622614772-543196@atomide.com Signed-off-by: Olof Johansson <olof@lixom.net>
| | * | ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_powerMaciej Falkowski2021-05-261-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ams_delta_camera_power() function is unused as reports Clang compilation with omap1_defconfig on linux-next: arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function 'ams_delta_camera_power' [-Wunused-function] static int ams_delta_camera_power(struct device *dev, int power) ^ 1 warning generated. The soc_camera support was dropped without removing ams_delta_camera_power() function, making it unused. Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies") Signed-off-by: Maciej Falkowski <maciej.falkowski9@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1326
| | * | ARM: OMAP2+: Fix build warning when mmc_omap is not builtYongqiang Liu2021-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC reports the following warning with W=1: arch/arm/mach-omap2/board-n8x0.c:325:19: warning: variable 'index' set but not used [-Wunused-but-set-variable] 325 | int bit, *openp, index; | ^~~~~ Fix this by moving CONFIG_MMC_OMAP to cover the rest codes in the n8x0_mmc_callback(). Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | ARM: OMAP1: isp1301-omap: Add missing gpiod_add_lookup_table functionMaciej Falkowski2021-05-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpiod table was added without any usage making it unused as reported by Clang compilation from omap1_defconfig on linux-next: arch/arm/mach-omap1/board-h2.c:347:34: warning: unused variable 'isp1301_gpiod_table' [-Wunused-variable] static struct gpiod_lookup_table isp1301_gpiod_table = { ^ 1 warning generated. The patch adds the missing gpiod_add_lookup_table() function. Signed-off-by: Maciej Falkowski <maciej.falkowski9@gmail.com> Fixes: f3ef38160e3d ("usb: isp1301-omap: Convert to use GPIO descriptors") Link: https://github.com/ClangBuiltLinux/linux/issues/1325 Signed-off-by: Tony Lindgren <tony@atomide.com>
| | * | ARM: OMAP1: Fix use of possibly uninitialized irq variableMaciej Falkowski2021-05-181-3/+7
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current control flow of IRQ number assignment to `irq` variable allows a request of IRQ of unspecified value, generating a warning under Clang compilation with omap1_defconfig on linux-next: arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] else if (cpu_is_omap16xx()) ^~~~~~~~~~~~~~~~~ ./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro 'cpu_is_omap16xx' ^~~~~~~~~~~~~ arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", ^~~ arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is always true else if (cpu_is_omap16xx()) ^~~~~~~~~~~~~~~~~~~~~~ arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to silence this warning int irq; ^ = 0 1 warning generated. The patch provides a default value to the `irq` variable along with a validity check. Signed-off-by: Maciej Falkowski <maciej.falkowski9@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/1324 Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | Merge tag 'amlogic-fixes-v5.13-rc1' of ↵Olof Johansson2021-06-051-0/+1
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into arm/fixes Amlogic fixes for v5.13-rc1 - arm64: meson: select COMMON_CLK to select a proper implementation of the clock API - soc: amlogic: meson-clk-measure: remove redundant dev_err call in meson_msr_probe() * tag 'amlogic-fixes-v5.13-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: arm64: meson: select COMMON_CLK soc: amlogic: meson-clk-measure: remove redundant dev_err call in meson_msr_probe() Link: https://lore.kernel.org/r/73e76706-f3f4-bebf-10dd-d2ec9106a234@baylibre.com Signed-off-by: Olof Johansson <olof@lixom.net>
| | * | arm64: meson: select COMMON_CLKJerome Brunet2021-05-311-0/+1
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fix the recent removal of clock drivers selection. While it is not necessary to select the clock drivers themselves, we need to select a proper implementation of the clock API, which for the meson, is CCF Fixes: ba66a25536dd ("arm64: meson: ship only the necessary clock controllers") Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210429083823.59546-1-jbrunet@baylibre.com
| * | Merge tag 'imx-fixes-5.13' of ↵Olof Johansson2021-06-0511-31/+39
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes i.MX fixes for 5.13: - Fix missing-prototypes warning of 'imx27_pm_init' in i.MX27 platform pm code. - A couple of patches from Fabio Estevam to fix 'tuning-step' property in imx7d-meerkat96 and imx7d-pico DT. - Fix '#gpio-cells' of nxp,pca8574 device in imx6qdl-emcon-avari DT. - A couple of patches from Lucas Stach to fix regulator and voltage for imx8mq-zii-ultra board. - Add missing regulators for imx6q-dhcom to avoid possible instability issues. - Fix memory-controller settings for fsl-ls1028a DT. - Fix RGMII clock and voltage for a couple of fsl-ls1028a-kontron-sl28 boards. - Fix RGMII connection to QCA8334 switch for imx6dl-yapp4 board. * tag 'imx-fixes-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cells ARM: dts: imx7d-pico: Fix the 'tuning-step' property ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' property arm64: dts: freescale: sl28: var1: fix RGMII clock and voltage arm64: dts: freescale: sl28: var4: fix RGMII clock and voltage ARM: imx: pm-imx27: Include "common.h" arm64: dts: zii-ultra: fix 12V_MAIN voltage arm64: dts: zii-ultra: remove second GEN_3V3 regulator instance arm64: dts: ls1028a: fix memory node ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulators ARM: dts: imx6dl-yapp4: Fix RGMII connection to QCA8334 switch Link: https://lore.kernel.org/r/20210527011758.GD8194@dragon Signed-off-by: Olof Johansson <olof@lixom.net>
| | * | ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cellsGeert Uytterhoeven2021-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the DT bindings, #gpio-cells must be two. Fixes: 63e71fedc07c4ece ("ARM: dts: Add support for emtrion emCON-MX6 series") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: imx7d-pico: Fix the 'tuning-step' propertyFabio Estevam2021-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml, the correct name of the property is 'fsl,tuning-step'. Fix it accordingly. Signed-off-by: Fabio Estevam <festevam@gmail.com> Fixes: f13f571ac8a1 ("ARM: dts: imx7d-pico: Extend peripherals support") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' propertyFabio Estevam2021-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml, the correct name of the property is 'fsl,tuning-step'. Fix it accordingly. Signed-off-by: Fabio Estevam <festevam@gmail.com> Fixes: ae7b3384b61b ("ARM: dts: Add support for 96Boards Meerkat96 board") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: freescale: sl28: var1: fix RGMII clock and voltageMichael Walle2021-05-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong, it was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var1.dts. Fixes: 642856097c18 ("arm64: dts: freescale: sl28: add variant 1") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: freescale: sl28: var4: fix RGMII clock and voltageMichael Walle2021-05-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During hardware validation it was noticed that the clock isn't continuously enabled when there is no link. This is because the 125MHz clock is derived from the internal PLL which seems to go into some kind of power-down mode every once in a while. The LS1028A expects a contiuous clock. Thus enable the PLL all the time. Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO regulator. This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts. Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: imx: pm-imx27: Include "common.h"Fabio Estevam2021-05-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 879c0e5e0ac7 ("ARM: imx: Remove i.MX27 board files") the following W=1 build warning is seen: arch/arm/mach-imx/pm-imx27.c:40:13: warning: no previous prototype for 'imx27_pm_init' [-Wmissing-prototypes] Fix it by including the "common.h" header file, which contains the prototype for imx27_pm_init(). Fixes: 879c0e5e0ac7 ("ARM: imx: Remove i.MX27 board files") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: zii-ultra: fix 12V_MAIN voltageLucas Stach2021-05-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As this is a fixed regulator on the board there was no harm in the wrong voltage being specified, apart from a confusing reporting to userspace. Fixes: 4a13b3bec3b4 ("arm64: dts: imx: add Zii Ultra board support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: zii-ultra: remove second GEN_3V3 regulator instanceLucas Stach2021-05-232-19/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding the sound support a second instance of the GEN_3V3 regulator was added by accident. Remove it and point the consumers to the first instance. Fixes: 663a5b5efa51 ("arm64: dts: zii-ultra: add sound support") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | arm64: dts: ls1028a: fix memory nodeMichael Walle2021-05-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While enabling EDAC support for the LS1028A it was discovered that the memory node has a wrong endianness setting as well as a wrong interrupt assignment. Fix both. This was tested on a sl28 board. To force ECC errors, you can use the error injection supported by the controller in hardware (with CONFIG_EDAC_DEBUG enabled): # enable error injection $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl # flip lowest bit of the data $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulatorsMarek Vasut2021-05-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1 via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs. While no instability or problems are currently observed, the regulators should be fully described in DT and that description should fully match the hardware, else this might lead to unforseen issues later. Fix this. Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2") Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Ludwig Zenz <lzenz@dh-electronics.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: stable@vger.kernel.org Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
| | * | ARM: dts: imx6dl-yapp4: Fix RGMII connection to QCA8334 switchMichal Vokáč2021-05-131-1/+5
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FEC does not have a PHY so it should not have a phy-handle. It is connected to the switch at RGMII level so we need a fixed-link sub-node on both ends. This was not a problem until the qca8k.c driver was converted to PHYLINK by commit b3591c2a3661 ("net: dsa: qca8k: Switch to PHYLINK instead of PHYLIB"). That commit revealed the FEC configuration was not correct. Fixes: 87489ec3a77f ("ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards") Cc: stable@vger.kernel.org Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
* | | Merge tag 'powerpc-5.13-5' of ↵Linus Torvalds2021-06-068-57/+49
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "Fix our KVM reverse map real-mode handling since we enabled huge vmalloc (in some configurations). Revert a recent change to our IOMMU code which broke some devices. Fix KVM handling of FSCR on P7/P8, which could have possibly let a guest crash it's Qemu. Fix kprobes validation of prefixed instructions across page boundary. Thanks to Alexey Kardashevskiy, Christophe Leroy, Fabiano Rosas, Frederic Barrat, Naveen N. Rao, and Nicholas Piggin" * tag 'powerpc-5.13-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: Revert "powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs" KVM: PPC: Book3S HV: Save host FSCR in the P7/8 path powerpc: Fix reverse map real-mode address lookup with huge vmalloc powerpc/kprobes: Fix validation of prefixed instructions across page boundary
| * | | Revert "powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs"Frederic Barrat2021-06-011-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 3c0468d4451eb6b4f6604370639f163f9637a479. That commit was breaking alignment guarantees for the DMA address when allocating coherent mappings, as described in Documentation/core-api/dma-api-howto.rst It was also noticed by Mellanox' driver: [ 1515.763621] mlx5_core c002:01:00.0: mlx5_frag_buf_alloc_node:146:(pid 13402): unexpected map alignment: 0x0800000000c61000, page_shift=16 [ 1515.763635] mlx5_core c002:01:00.0: mlx5_cqwq_create:181:(pid 13402): mlx5_frag_buf_alloc_node() failed, -12 Fixes: 3c0468d4451e ("powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs") Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210526144540.117795-1-fbarrat@linux.ibm.com
| * | | KVM: PPC: Book3S HV: Save host FSCR in the P7/8 pathNicholas Piggin2021-05-282-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to commit 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path"), ensure the P7/8 path saves and restores the host FSCR. The logic explained in that patch actually applies there to the old path well: a context switch can be made before kvmppc_vcpu_run_hv restores the host FSCR and returns. Now both the p9 and the p7/8 paths now save and restore their FSCR, it no longer needs to be restored at the end of kvmppc_vcpu_run_hv Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs") Cc: stable@vger.kernel.org # v3.14+ Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210526125851.3436735-1-npiggin@gmail.com
| * | | powerpc: Fix reverse map real-mode address lookup with huge vmallocNicholas Piggin2021-05-284-48/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | real_vmalloc_addr() does not currently work for huge vmalloc, which is what the reverse map can be allocated with for radix host, hash guest. Extract the hugepage aware equivalent from eeh code into a helper, and convert existing sites including this one to use it. Fixes: 8abddd968a30 ("powerpc/64s/radix: Enable huge vmalloc mappings") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210526120005.3432222-1-npiggin@gmail.com
| * | | powerpc/kprobes: Fix validation of prefixed instructions across page boundaryNaveen N. Rao2021-05-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When checking if the probed instruction is the suffix of a prefixed instruction, we access the instruction at the previous word. If the probed instruction is the very first word of a module, we can end up trying to access an invalid page. Fix this by skipping the check for all instructions at the beginning of a page. Prefixed instructions cannot cross a 64-byte boundary and as such, we don't expect to encounter a suffix as the very first word in a page for kernel text. Even if there are prefixed instructions crossing a page boundary (from a module, for instance), the instruction will be illegal, so preventing probing on the suffix of such prefix instructions isn't worthwhile. Fixes: b4657f7650ba ("powerpc/kprobes: Don't allow breakpoints on suffixes") Cc: stable@vger.kernel.org # v5.8+ Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/0df9a032a05576a2fa8e97d1b769af2ff0eafbd6.1621416666.git.naveen.n.rao@linux.vnet.ibm.com
* | | | Merge tag 'x86_urgent_for_v5.13-rc5' of ↵Linus Torvalds2021-06-0614-120/+132
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: "A bunch of x86/urgent stuff accumulated for the last two weeks so lemme unload it to you. It should be all totally risk-free, of course. :-) - Fix out-of-spec hardware (1st gen Hygon) which does not implement MSR_AMD64_SEV even though the spec clearly states so, and check CPUID bits first. - Send only one signal to a task when it is a SEGV_PKUERR si_code type. - Do away with all the wankery of reserving X amount of memory in the first megabyte to prevent BIOS corrupting it and simply and unconditionally reserve the whole first megabyte. - Make alternatives NOP optimization work at an arbitrary position within the patched sequence because the compiler can put single-byte NOPs for alignment anywhere in the sequence (32-bit retpoline), vs our previous assumption that the NOPs are only appended. - Force-disable ENQCMD[S] instructions support and remove update_pasid() because of insufficient protection against FPU state modification in an interrupt context, among other xstate horrors which are being addressed at the moment. This one limits the fallout until proper enablement. - Use cpu_feature_enabled() in the idxd driver so that it can be build-time disabled through the defines in disabled-features.h. - Fix LVT thermal setup for SMI delivery mode by making sure the APIC LVT value is read before APIC initialization so that softlockups during boot do not happen at least on one machine. - Mark all legacy interrupts as legacy vectors when the IO-APIC is disabled and when all legacy interrupts are routed through the PIC" * tag 'x86_urgent_for_v5.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sev: Check SME/SEV support in CPUID first x86/fault: Don't send SIGSEGV twice on SEGV_PKUERR x86/setup: Always reserve the first 1M of RAM x86/alternative: Optimize single-byte NOPs at an arbitrary position x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid() dmaengine: idxd: Use cpu_feature_enabled() x86/thermal: Fix LVT thermal setup for SMI delivery mode x86/apic: Mark _all_ legacy interrupts when IO/APIC is missing
| * | | | x86/sev: Check SME/SEV support in CPUID firstPu Wen2021-06-041-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first two bits of the CPUID leaf 0x8000001F EAX indicate whether SEV or SME is supported, respectively. It's better to check whether SEV or SME is actually supported before accessing the MSR_AMD64_SEV to check whether SEV or SME is enabled. This is both a bare-metal issue and a guest/VM issue. Since the first generation Hygon Dhyana CPU doesn't support the MSR_AMD64_SEV, reading that MSR results in a #GP - either directly from hardware in the bare-metal case or via the hypervisor (because the RDMSR is actually intercepted) in the guest/VM case, resulting in a failed boot. And since this is very early in the boot phase, rdmsrl_safe()/native_read_msr_safe() can't be used. So check the CPUID bits first, before accessing the MSR. [ tlendacky: Expand and improve commit message. ] [ bp: Massage commit message. ] Fixes: eab696d8e8b9 ("x86/sev: Do not require Hypervisor CPUID bit for SEV guests") Signed-off-by: Pu Wen <puwen@hygon.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@vger.kernel.org> # v5.10+ Link: https://lkml.kernel.org/r/20210602070207.2480-1-puwen@hygon.cn
| * | | | x86/fault: Don't send SIGSEGV twice on SEGV_PKUERRJiashuo Liang2021-06-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __bad_area_nosemaphore() calls both force_sig_pkuerr() and force_sig_fault() when handling SEGV_PKUERR. This does not cause problems because the second signal is filtered by the legacy_queue() check in __send_signal() because in both cases, the signal is SIGSEGV, the second one seeing that the first one is already pending. This causes the kernel to do unnecessary work so send the signal only once for SEGV_PKUERR. [ bp: Massage commit message. ] Fixes: 9db812dbb29d ("signal/x86: Call force_sig_pkuerr from __bad_area_nosemaphore") Suggested-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Jiashuo Liang <liangjs@pku.edu.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Link: https://lkml.kernel.org/r/20210601085203.40214-1-liangjs@pku.edu.cn
| * | | | x86/setup: Always reserve the first 1M of RAMMike Rapoport2021-06-033-20/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are BIOSes that are known to corrupt the memory under 1M, or more precisely under 640K because the memory above 640K is anyway reserved for the EGA/VGA frame buffer and BIOS. To prevent usage of the memory that will be potentially clobbered by the kernel, the beginning of the memory is always reserved. The exact size of the reserved area is determined by CONFIG_X86_RESERVE_LOW build time and the "reservelow=" command line option. The reserved range may be from 4K to 640K with the default of 64K. There are also configurations that reserve the entire 1M range, like machines with SandyBridge graphic devices or systems that enable crash kernel. In addition to the potentially clobbered memory, EBDA of unknown size may be as low as 128K and the memory above that EBDA start is also reserved early. It would have been possible to reserve the entire range under 1M unless for the real mode trampoline that must reside in that area. To accommodate placement of the real mode trampoline and keep the memory safe from being clobbered by BIOS, reserve the first 64K of RAM before memory allocations are possible and then, after the real mode trampoline is allocated, reserve the entire range from 0 to 1M. Update trim_snb_memory() and reserve_real_mode() to avoid redundant reservations of the same memory range. Also make sure the memory under 1M is not getting freed by efi_free_boot_services(). [ bp: Massage commit message and comments. ] Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations") Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Hugh Dickins <hughd@google.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=213177 Link: https://lkml.kernel.org/r/20210601075354.5149-2-rppt@kernel.org
| * | | | x86/alternative: Optimize single-byte NOPs at an arbitrary positionBorislav Petkov2021-06-031-18/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now the assumption was that an alternative patching site would have some instructions at the beginning and trailing single-byte NOPs (0x90) padding. Therefore, the patching machinery would go and optimize those single-byte NOPs into longer ones. However, this assumption is broken on 32-bit when code like hv_do_hypercall() in hyperv_init() would use the ratpoline speculation killer CALL_NOSPEC. The 32-bit version of that macro would align certain insns to 16 bytes, leading to the compiler issuing a one or more single-byte NOPs, depending on the holes it needs to fill for alignment. That would lead to the warning in optimize_nops() to fire: ------------[ cut here ]------------ Not a NOP at 0xc27fb598 WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:211 optimize_nops.isra.13 due to that function verifying whether all of the following bytes really are single-byte NOPs. Therefore, carve out the NOP padding into a separate function and call it for each NOP range beginning with a single-byte NOP. Fixes: 23c1ad538f4f ("x86/alternatives: Optimize optimize_nops()") Reported-by: Richard Narron <richard@aaazen.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=213301 Link: https://lkml.kernel.org/r/20210601212125.17145-1-bp@alien8.de
| * | | | x86/cpufeatures: Force disable X86_FEATURE_ENQCMD and remove update_pasid()Thomas Gleixner2021-06-034-74/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While digesting the XSAVE-related horrors which got introduced with the supervisor/user split, the recent addition of ENQCMD-related functionality got on the radar and turned out to be similarly broken. update_pasid(), which is only required when X86_FEATURE_ENQCMD is available, is invoked from two places: 1) From switch_to() for the incoming task 2) Via a SMP function call from the IOMMU/SMV code #1 is half-ways correct as it hacks around the brokenness of get_xsave_addr() by enforcing the state to be 'present', but all the conditionals in that code are completely pointless for that. Also the invocation is just useless overhead because at that point it's guaranteed that TIF_NEED_FPU_LOAD is set on the incoming task and all of this can be handled at return to user space. #2 is broken beyond repair. The comment in the code claims that it is safe to invoke this in an IPI, but that's just wishful thinking. FPU state of a running task is protected by fregs_lock() which is nothing else than a local_bh_disable(). As BH-disabled regions run usually with interrupts enabled the IPI can hit a code section which modifies FPU state and there is absolutely no guarantee that any of the assumptions which are made for the IPI case is true. Also the IPI is sent to all CPUs in mm_cpumask(mm), but the IPI is invoked with a NULL pointer argument, so it can hit a completely unrelated task and unconditionally force an update for nothing. Worse, it can hit a kernel thread which operates on a user space address space and set a random PASID for it. The offending commit does not cleanly revert, but it's sufficient to force disable X86_FEATURE_ENQCMD and to remove the broken update_pasid() code to make this dysfunctional all over the place. Anything more complex would require more surgery and none of the related functions outside of the x86 core code are blatantly wrong, so removing those would be overkill. As nothing enables the PASID bit in the IA32_XSS MSR yet, which is required to make this actually work, this cannot result in a regression except for related out of tree train-wrecks, but they are broken already today. Fixes: 20f0afd1fb3d ("x86/mmu: Allocate/free a PASID") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Andy Lutomirski <luto@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtsd6gr9.ffs@nanos.tec.linutronix.de
| * | | | x86/thermal: Fix LVT thermal setup for SMI delivery modeBorislav Petkov2021-05-312-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are machines out there with added value crap^WBIOS which provide an SMI handler for the local APIC thermal sensor interrupt. Out of reset, the BSP on those machines has something like 0x200 in that APIC register (timestamps left in because this whole issue is timing sensitive): [ 0.033858] read lvtthmr: 0x330, val: 0x200 which means: - bit 16 - the interrupt mask bit is clear and thus that interrupt is enabled - bits [10:8] have 010b which means SMI delivery mode. Now, later during boot, when the kernel programs the local APIC, it soft-disables it temporarily through the spurious vector register: setup_local_APIC: ... /* * If this comes from kexec/kcrash the APIC might be enabled in * SPIV. Soft disable it before doing further initialization. */ value = apic_read(APIC_SPIV); value &= ~APIC_SPIV_APIC_ENABLED; apic_write(APIC_SPIV, value); which means (from the SDM): "10.4.7.2 Local APIC State After It Has Been Software Disabled ... * The mask bits for all the LVT entries are set. Attempts to reset these bits will be ignored." And this happens too: [ 0.124111] APIC: Switch to symmetric I/O mode setup [ 0.124117] lvtthmr 0x200 before write 0xf to APIC 0xf0 [ 0.124118] lvtthmr 0x10200 after write 0xf to APIC 0xf0 This results in CPU 0 soft lockups depending on the placement in time when the APIC soft-disable happens. Those soft lockups are not 100% reproducible and the reason for that can only be speculated as no one tells you what SMM does. Likely, it confuses the SMM code that the APIC is disabled and the thermal interrupt doesn't doesn't fire at all, leading to CPU 0 stuck in SMM forever... Now, before 4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()") due to how the APIC_LVTTHMR was read before APIC initialization in mcheck_intel_therm_init(), it would read the value with the mask bit 16 clear and then intel_init_thermal() would replicate it onto the APs and all would be peachy - the thermal interrupt would remain enabled. But that commit moved that reading to a later moment in intel_init_thermal(), resulting in reading APIC_LVTTHMR on the BSP too late and with its interrupt mask bit set. Thus, revert back to the old behavior of reading the thermal LVT register before the APIC gets initialized. Fixes: 4f432e8bb15b ("x86/mce: Get rid of mcheck_intel_therm_init()") Reported-by: James Feeney <james@nurealm.net> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lkml.kernel.org/r/YKIqDdFNaXYd39wz@zn.tnic
| * | | | x86/apic: Mark _all_ legacy interrupts when IO/APIC is missingThomas Gleixner2021-05-293-0/+22
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PIC interrupts do not support affinity setting and they can end up on any online CPU. Therefore, it's required to mark the associated vectors as system-wide reserved. Otherwise, the corresponding irq descriptors are copied to the secondary CPUs but the vectors are not marked as assigned or reserved. This works correctly for the IO/APIC case. When the IO/APIC is disabled via config, kernel command line or lack of enumeration then all legacy interrupts are routed through the PIC, but nothing marks them as system-wide reserved vectors. As a consequence, a subsequent allocation on a secondary CPU can result in allocating one of these vectors, which triggers the BUG() in apic_update_vector() because the interrupt descriptor slot is not empty. Imran tried to work around that by marking those interrupts as allocated when a CPU comes online. But that's wrong in case that the IO/APIC is available and one of the legacy interrupts, e.g. IRQ0, has been switched to PIC mode because then marking them as allocated will fail as they are already marked as system vectors. Stay consistent and update the legacy vectors after attempting IO/APIC initialization and mark them as system vectors in case that no IO/APIC is available. Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment") Reported-by: Imran Khan <imran.f.khan@oracle.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20210519233928.2157496-1-imran.f.khan@oracle.com
* | | | Merge branch 'akpm' (patches from Andrew)Linus Torvalds2021-06-051-16/+14
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge misc fixes from Andrew Morton: "13 patches. Subsystems affected by this patch series: mips, mm (kfence, debug, pagealloc, memory-hotplug, hugetlb, kasan, and hugetlb), init, proc, lib, ocfs2, and mailmap" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mailmap: use private address for Michel Lespinasse ocfs2: fix data corruption by fallocate lib: crc64: fix kernel-doc warning mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY mm/kasan/init.c: fix doc warning proc: add .gitignore for proc-subset-pid selftest hugetlb: pass head page to remove_hugetlb_page() drivers/base/memory: fix trying offlining memory blocks with memory holes on aarch64 mm/page_alloc: fix counting of free pages after take off from buddy mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests() pid: take a reference when initializing `cad_pid` kfence: use TASK_IDLE when awaiting allocation Revert "MIPS: make userspace mapping young by default"
| * | | | Revert "MIPS: make userspace mapping young by default"Thomas Bogendoerfer2021-06-051-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f685a533a7fab35c5d069dcd663f59c8e4171a75. The MIPS cache flush logic needs to know whether the mapping was already established to decide how to flush caches. This is done by checking the valid bit in the PTE. The commit above breaks this logic by setting the valid in the PTE in new mappings, which causes kernel crashes. Link: https://lkml.kernel.org/r/20210526094335.92948-1-tsbogend@alpha.franken.de Fixes: f685a533a7f ("MIPS: make userspace mapping young by default") Reported-by: Zhou Yanjie <zhouyanjie@wanyeetech.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Huang Pei <huangpei@loongson.cn> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | | | Merge tag 'riscv-for-linus-5.13-rc5' of ↵Linus Torvalds2021-06-054-5/+18
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - Build with '-mno-relax' when using LLVM's linker, which doesn't support linker relaxation. - A fix to build without SiFive's errata. - A fix to use PAs during init_resources() - A fix to avoid W+X mappings during boot. * tag 'riscv-for-linus-5.13-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Fix memblock_free() usages in init_resources() riscv: skip errata_cip_453.o if CONFIG_ERRATA_SIFIVE_CIP_453 is disabled riscv: mm: Fix W+X mappings at boot riscv: Use -mno-relax when using lld linker
| * | | | Merge remote-tracking branch 'riscv/riscv-wx-mappings' into fixesPalmer Dabbelt2021-06-011-2/+6
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This single commit is shared between fixes and for-next, as it fixes a concrete bug while likely conflicting with a more invasive cleanup to avoid these oddball mappings entirely. * riscv/riscv-wx-mappings: riscv: mm: Fix W+X mappings at boot
| | * | | | riscv: mm: Fix W+X mappings at bootJisheng Zhang2021-06-011-2/+6
| | | |_|/ | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the kernel mapping was moved the last 2GB of the address space, (__va(PFN_PHYS(max_low_pfn))) is much smaller than the .data section start address, the last set_memory_nx() in protect_kernel_text_data() will fail, thus the .data section is still mapped as W+X. This results in below W+X mapping waring at boot. Fix it by passing the correct .data section page num to the set_memory_nx(). [ 0.396516] ------------[ cut here ]------------ [ 0.396889] riscv/mm: Found insecure W+X mapping at address (____ptrval____)/0xffffffff80c00000 [ 0.398347] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/ptdump.c:258 note_page+0x244/0x24a [ 0.398964] Modules linked in: [ 0.399459] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1+ #14 [ 0.400003] Hardware name: riscv-virtio,qemu (DT) [ 0.400591] epc : note_page+0x244/0x24a [ 0.401368] ra : note_page+0x244/0x24a [ 0.401772] epc : ffffffff80007c86 ra : ffffffff80007c86 sp : ffffffe000e7bc30 [ 0.402304] gp : ffffffff80caae88 tp : ffffffe000e70000 t0 : ffffffff80cb80cf [ 0.402800] t1 : ffffffff80cb80c0 t2 : 0000000000000000 s0 : ffffffe000e7bc80 [ 0.403310] s1 : ffffffe000e7bde8 a0 : 0000000000000053 a1 : ffffffff80c83ff0 [ 0.403805] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 6c7e7a5137233100 [ 0.404298] a5 : 6c7e7a5137233100 a6 : 0000000000000030 a7 : ffffffffffffffff [ 0.404849] s2 : ffffffff80e00000 s3 : 0000000040000000 s4 : 0000000000000000 [ 0.405393] s5 : 0000000000000000 s6 : 0000000000000003 s7 : ffffffe000e7bd48 [ 0.405935] s8 : ffffffff81000000 s9 : ffffffffc0000000 s10: ffffffe000e7bd48 [ 0.406476] s11: 0000000000001000 t3 : 0000000000000072 t4 : ffffffffffffffff [ 0.407016] t5 : 0000000000000002 t6 : ffffffe000e7b978 [ 0.407435] status: 0000000000000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 0.408052] Call Trace: [ 0.408343] [<ffffffff80007c86>] note_page+0x244/0x24a [ 0.408855] [<ffffffff8010c5a6>] ptdump_hole+0x14/0x1e [ 0.409263] [<ffffffff800f65c6>] walk_pgd_range+0x2a0/0x376 [ 0.409690] [<ffffffff800f6828>] walk_page_range_novma+0x4e/0x6e [ 0.410146] [<ffffffff8010c5f8>] ptdump_walk_pgd+0x48/0x78 [ 0.410570] [<ffffffff80007d66>] ptdump_check_wx+0xb4/0xf8 [ 0.410990] [<ffffffff80006738>] mark_rodata_ro+0x26/0x2e [ 0.411407] [<ffffffff8031961e>] kernel_init+0x44/0x108 [ 0.411814] [<ffffffff80002312>] ret_from_exception+0x0/0xc [ 0.412309] ---[ end trace 7ec3459f2547ea83 ]--- [ 0.413141] Checked W+X mappings: failed, 512 W+X pages found Fixes: 2bfc6cd81bd17e43 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
| * | | | RISC-V: Fix memblock_free() usages in init_resources()Wende Tan2021-06-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `memblock_free()` takes a physical address as its first argument. Fix the wrong usages in `init_resources()`. Fixes: ffe0e526126884cf036a6f724220f1f9b4094fd2 ("RISC-V: Improve init_resources()") Fixes: 797f0375dd2ef5cdc68ac23450cbae9a5c67a74e ("RISC-V: Do not allocate memblock while iterating reserved memblocks") Signed-off-by: Wende Tan <twd2.me@gmail.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
| * | | | riscv: skip errata_cip_453.o if CONFIG_ERRATA_SIFIVE_CIP_453 is disabledVincent2021-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The errata_cip_453.o should be built only when the Kconfig CONFIG_ERRATA_SIFIVE_CIP_453 is enabled. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Vincent <vincent.chen@sifive.com> Fixes: 0e0d4992517f ("riscv: enable SiFive errata CIP-453 and CIP-1200 Kconfig only if CONFIG_64BIT=y") Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
| * | | | riscv: Use -mno-relax when using lld linkerKhem Raj2021-05-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lld does not implement the RISCV relaxation optimizations like GNU ld therefore disable it when building with lld, Also pass it to assembler when using external GNU assembler ( LLVM_IAS != 1 ), this ensures that relevant assembler option is also enabled along. if these options are not used then we see following relocations in objects 0000000000000000 R_RISCV_ALIGN *ABS*+0x0000000000000002 These are then rejected by lld ld.lld: error: capability.c:(.fixup+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax but the .o is already compiled with -mno-relax Signed-off-by: Khem Raj <raj.khem@gmail.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 21:47:40 +0000