summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-02-12arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / TentacoolChen-Yu Tsai
Tentacruel and Tentacool are MT8186 based Chromebooks based on the Krabby design. Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a convertible device with touchscreen and stylus. Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop device. It does not have a touchscreen or stylus. The two devices both have two variants. The difference is a second source trackpad controller that shares the same address as the original, but is incompatible. The extra SKU IDs for the Tentacruel devices map to different sensor components attached to the Embedded Controller. These are not visible to the main processor. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-7-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add jpgenc nodeAllen-KH Cheng
Add JPEG encoder node. Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Max Staudt <mstaudt@chromium.org> Tested-by: Max Staudt <mstaudt@chromium.org> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240127084258.68302-2-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add venc nodeKyrie Wu
Add video encoder node. Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-7-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: fix VENC power domain clocksEugen Hristev
The larb clock is in fact a subsys clock, so it must be prefixed by 'subsys-' to be correctly identified in the driver. Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-6-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192: fix vencoder clock nameEugen Hristev
Clock name should be `venc_sel` as per binding. Fix the warning message : arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec@17020000: clock-names:0: 'venc_sel' was expected from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-4-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add socinfo efuses to MT8173/83/96/92/95 SoCsWilliam-tw Lin
Add efuse nodes for socinfo retrieval for MT8173, MT8183, MT8186, MT8192 and MT8195. Signed-off-by: William-tw Lin <william-tw.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231222080739.21706-2-william-tw.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8195: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.12.Iee33a7f1f991408cef372744199026f936bf54e2@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.11.Ibd330d26a00f5e219a7e448452769124833a9762@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8183: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.10.Iba4a8b7e908989e57f7838a80013a4062be5e614@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8173: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.9.Ic09ebe116c18e83cc1161f4bb073fea8043f03f3@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7988: add clock controllersRafał Miłecki
Add bindings of on-SoC clocks. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20240108085228.4727-4-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add initial MT7988A and BPI-R4Rafał Miłecki
MT7988A (AKA MediaTek Filogic 880) is a quad-core ARM Cortex-A73 platform designed for Wi-Fi 7 devices (there is no wireless on SoC though). The first public MT7988A device is Banana Pi BPI-R4. Many SoC parts remain to be added (they need their own bindings or depend on missing clocks). Those present block however are correct and having base .dtsi will help testing & working on missing stuff. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240108085228.4727-3-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add initial MT7981B and Xiaomi AX3000TRafał Miłecki
MT7981B (AKA MediaTek Filogic 820) is a dual-core ARM Cortex-A53 SoC. One of market devices using this SoC is Xiaomi AX3000T. This is initial contribution with basic SoC support. More hardware block will get added later. Some will need their bindings (like auxadc). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240111103928.721-3-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection nodeNícolas F. R. A. Prado
The commit adding the ChromeOS EC to the Asurada Devicetree mistakenly added a base detection node. While tablet mode detection is supported by CrosEC and used by Hayato, it is done through the cros-ec-keyb driver. The base detection node, which is handled by the hid-google-hammer driver, also provides tablet mode detection but by checking base attachment status on the CrosEC, which is not supported for Asurada. Hence, remove the unused CrosEC base detection node for Asurada. Fixes: eb188a2aaa82 ("arm64: dts: mediatek: asurada: Add ChromeOS EC") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240207-mt8192-asurada-cbas-remove-v1-1-04cb65951975@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfgRafał Miłecki
MT7986's Infrastructure System Configuration Controller includes reset controller. It can reset blocks as specified in the include/dt-bindings/reset/mt7986-resets.h . Add #reset-cells so it can be referenced properly. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: infracfg@10001000: '#reset-cells' is a required property from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml# Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a") Cc: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240101182040.28538-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: drop "#clock-cells" from PWMRafał Miłecki
PWM is not a clock provider and its binding doesn't specify "#clock-cells" property. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm@10048000: '#clock-cells' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/pwm/mediatek,mt2712-pwm.yaml# Fixes: eabb04df46c6 ("arm64: dts: mt7986: add PWM") Cc: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240101182040.28538-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: fix SPI nodenameRafał Miłecki
This fixes following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116130952.5099-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: fix SPI bus width propertiesRafał Miłecki
This fixes SPI setup and resolves following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116130952.5099-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock nameRafał Miłecki
According to the "inside-secure,safexcel-eip97" binding "clock-names" is required only if there are two clocks specified. If present the first name must by "core". Name "infra_eip97_ck" is invalid and was probably just a typo. Drop it. Fixes: ecc5287cfe53 ("arm64: dts: mt7986: add crypto related device nodes") Cc: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116132411.7665-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: fix reference to PWM in fan nodeRafał Miłecki
This fixes typo and resolves following validation error: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[54, 0, 10000], [0]] is too long from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml# Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts") Cc: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116130816.4932-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTsNícolas F. R. A. Prado
The cbas node is used to describe base detection functionality in the ChromeOS EC, which is used for units that have a detachable keyboard and thus rely on this functionality to switch between tablet and laptop mode. Despite the original commit having added the cbas node to the mt8183-kukui.dtsi, not all machines that include it are detachables. In fact all machines that include from mt8183-kukui-jacuzzi.dtsi are either clamshells (ie normal laptops) or convertibles, meaning the keyboard can be flipped but not detached. The detection for the keyboard getting flipped is handled by the driver bound to the keyboard-controller node in the EC. Move the base detection node from the base kukui dtsi to the dtsis where all machines are detachables, and thus actually make use of the node. Fixes: 4fa8492d1e5b ("arm64: dts: mt8183: add cbas node under cros_ec") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240116-mt8183-kukui-cbas-remove-v3-1-055e21406e86@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12x86/retpoline: Ensure default return thunk isn't used at runtimeJosh Poimboeuf
Make sure the default return thunk is not used after all return instructions have been patched by the alternatives because the default return thunk is insufficient when it comes to mitigating Retbleed or SRSO. Fix based on an earlier version by David Kaplan <david.kaplan@amd.com>. [ bp: Fix the compilation error of warn_thunk_thunk being an invisible symbol, hoist thunk macro into calling.h ] Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Co-developed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231010171020.462211-4-david.kaplan@amd.com Link: https://lore.kernel.org/r/20240104132446.GEZZaxnrIgIyat0pqf@fat_crate.local
2024-02-12ARM: s3c64xx: make bus_type constRicardo B. Marliere
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the s3c6410_subsys variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240204-bus_cleanup-arm-v1-1-41d651dd8411@marliere.net Link: https://lore.kernel.org/r/20240211-bus_cleanup-arm-v2-1-3de9e8af7cbd@marliere.net Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-11Merge tag 'x86_urgent_for_v6.8_rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Correct the minimum CPU family for Transmeta Crusoe in Kconfig so that such hw can boot again - Do not take into accout XSTATE buffer size info supplied by userspace when constructing a sigreturn frame - Switch get_/put_user* to EX_TYPE_UACCESS exception handling when an MCE is encountered so that it can be properly recovered from instead of simply panicking * tag 'x86_urgent_for_v6.8_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6 x86/fpu: Stop relying on userspace for info to fault in xsave buffer x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups
2024-02-10Merge tag 'mm-hotfixes-stable-2024-02-10-11-16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "21 hotfixes. 12 are cc:stable and the remainder pertain to post-6.7 issues or aren't considered to be needed in earlier kernel versions" * tag 'mm-hotfixes-stable-2024-02-10-11-16' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (21 commits) nilfs2: fix potential bug in end_buffer_async_write mm/damon/sysfs-schemes: fix wrong DAMOS tried regions update timeout setup nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() MAINTAINERS: Leo Yan has moved mm/zswap: don't return LRU_SKIP if we have dropped lru lock fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super mailmap: switch email address for John Moon mm: zswap: fix objcg use-after-free in entry destruction mm/madvise: don't forget to leave lazy MMU mode in madvise_cold_or_pageout_pte_range() arch/arm/mm: fix major fault accounting when retrying under per-VMA lock selftests: core: include linux/close_range.h for CLOSE_RANGE_* macros mm/memory-failure: fix crash in split_huge_page_to_list from soft_offline_page mm: memcg: optimize parent iteration in memcg_rstat_updated() nilfs2: fix data corruption in dsync block recovery for small block sizes mm/userfaultfd: UFFDIO_MOVE implementation should use ptep_get() exit: wait_task_zombie: kill the no longer necessary spin_lock_irq(siglock) fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats fs/proc: do_task_stat: move thread_group_cputime_adjusted() outside of lock_task_sighand() getrusage: use sig->stats_lock rather than lock_task_sighand() getrusage: move thread_group_cputime_adjusted() outside of lock_task_sighand() ...
2024-02-09work around gcc bugs with 'asm goto' with outputsLinus Torvalds
We've had issues with gcc and 'asm goto' before, and we created a 'asm_volatile_goto()' macro for that in the past: see commits 3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation bug") and a9f180345f53 ("compiler/gcc4: Make quirk for asm_volatile_goto() unconditional"). Then, much later, we ended up removing the workaround in commit 43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR 58670") because we no longer supported building the kernel with the affected gcc versions, but we left the macro uses around. Now, Sean Christopherson reports a new version of a very similar problem, which is fixed by re-applying that ancient workaround. But the problem in question is limited to only the 'asm goto with outputs' cases, so instead of re-introducing the old workaround as-is, let's rename and limit the workaround to just that much less common case. It looks like there are at least two separate issues that all hit in this area: (a) some versions of gcc don't mark the asm goto as 'volatile' when it has outputs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420 which is easy to work around by just adding the 'volatile' by hand. (b) Internal compiler errors: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422 which are worked around by adding the extra empty 'asm' as a barrier, as in the original workaround. but the problem Sean sees may be a third thing since it involves bad code generation (not an ICE) even with the manually added 'volatile'. but the same old workaround works for this case, even if this feels a bit like voodoo programming and may only be hiding the issue. Reported-and-tested-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/ Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Uros Bizjak <ubizjak@gmail.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Andrew Pinski <quic_apinski@quicinc.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-02-09arm64: dts: qcom: qrb4210-rb2: enable USB-C port handlingDmitry Baryshkov
Plug in USB-C related bits and pieces to enable USB role switching and USB-C orientation handling for the Qualcomm RB2 board. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240130-pmi632-typec-v3-6-b05fe44f0a51@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-09arm64: dts: qcom: sm6115: drop pipe clock selectionVladimir Zapolskiy
Stop selecting UTMI clock as the USB3 PIPE clock. This setting is incompatible with the USB host working in USB3 (SuperSpeed) mode. While we are at it, also drop the default setting for the port speed. Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> [DB: fixed commit message, dropped dr_mode setting] Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # sdm632-fairphone-fp3 Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240130-pmi632-typec-v3-5-b05fe44f0a51@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-09arm64: dts: qcom: pmi632: define USB-C related blocksDmitry Baryshkov
Define VBUS regulator and the Type-C handling block as present on the Quacomm PMI632 PMIC. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # sdm632-fairphone-fp3 Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240130-pmi632-typec-v3-4-b05fe44f0a51@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-09drivers/ps3: select VIDEO to provide cmdline functionsRandy Dunlap
When VIDEO is not set, there is a build error. Fix that by selecting VIDEO for PS3_PS3AV. ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined! Fixes: dae7fbf43fd0 ("driver/ps3: Include <video/cmdline.h> for mode parsing") Fixes: a3b6792e990d ("video/cmdline: Introduce CONFIG_VIDEO for video= parameter") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Geoff Levand <geoff@infradead.org> Acked-by: Geoff Levand <geoff@infradead.org> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240207161322.8073-1-rdunlap@infradead.org
2024-02-09Merge tag 'riscv-for-linus-6.8-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - fix missing TLB flush during early boot on SPARSEMEM_VMEMMAP configurations - fixes to correctly implement the break-before-make behavior requried by the ISA for NAPOT mappings - fix a missing TLB flush on intermediate mapping changes - fix build warning about a missing declaration of overflow_stack - fix performace regression related to incorrect tracking of completed batch TLB flushes * tag 'riscv-for-linus-6.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Fix arch_tlbbatch_flush() by clearing the batch cpumask riscv: declare overflow_stack as exported from traps.c riscv: Fix arch_hugetlb_migration_supported() for NAPOT riscv: Flush the tlb when a page directory is freed riscv: Fix hugetlb_mask_last_page() when NAPOT is enabled riscv: Fix set_huge_pte_at() for NAPOT mapping riscv: mm: execute local TLB flush after populating vmemmap
2024-02-09Merge tag 'efi-fixes-for-v6.8-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "The only notable change here is the patch that changes the way we deal with spurious errors from the EFI memory attribute protocol. This will be backported to v6.6, and is intended to ensure that we will not paint ourselves into a corner when we tighten this further in order to comply with MS requirements on signed EFI code. Note that this protocol does not currently exist in x86 production systems in the field, only in Microsoft's fork of OVMF, but it will be mandatory for Windows logo certification for x86 PCs in the future. - Tighten ELF relocation checks on the RISC-V EFI stub - Give up if the new EFI memory attributes protocol fails spuriously on x86 - Take care not to place the kernel in the lowest 16 MB of DRAM on x86 - Omit special purpose EFI memory from memblock - Some fixes for the CXL CPER reporting code - Make the PE/COFF layout of mixed-mode capable images comply with a strict interpretation of the spec" * tag 'efi-fixes-for-v6.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section cxl/trace: Remove unnecessary memcpy's cxl/cper: Fix errant CPER prints for CXL events efi: Don't add memblocks for soft-reserved memory efi: runtime: Fix potential overflow of soft-reserved region size efi/libstub: Add one kernel-doc comment x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR x86/efistub: Give up if memory attribute protocol returns an error riscv/efistub: Tighten ELF relocation check riscv/efistub: Ensure GP-relative addressing is not used
2024-02-09arm64: dts: qcom: qcs6490-rb3gen2: Correct the voltage setting for vph_pwrKomal Bajaj
Min and max voltages for vph_pwr should be same, otherwise rpmh will not probe, so correcting the min and max voltages for vph_pwr. Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts") Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231220110015.25378-3-quic_kbajaj@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-09arm64: dts: qcom: qcm6490-idp: Correct the voltage setting for vph_pwrKomal Bajaj
Min and max voltages for vph_pwr should be same, otherwise rpmh will not probe, so correcting the min and max voltages for vph_pwr. Fixes: 9af6a9f32ad0 ("arm64: dts: qcom: Add base qcm6490 idp board dts") Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20231220110015.25378-2-quic_kbajaj@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-02-09arm64: jump_label: use constraints "Si" instead of "i"Fangrui Song
The generic constraint "i" seems to be copied from x86 or arm (and with a redundant generic operand modifier "c"). It works with -fno-PIE but not with -fPIE/-fPIC in GCC's aarch64 port. The machine constraint "S", which denotes a symbol or label reference with a constant offset, supports PIC and has been available in GCC since 2012 and in Clang since 7.0. However, Clang before 19 does not support "S" on a symbol with a constant offset [1] (e.g. `static_key_false(&nf_hooks_needed[pf][hook])` in include/linux/netfilter.h), so we use "i" as a fallback. Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Fangrui Song <maskray@google.com> Link: https://github.com/llvm/llvm-project/pull/80255 [1] Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20240206074552.541154-1-maskray@google.com Signed-off-by: Will Deacon <will@kernel.org>
2024-02-09arm64: fix typo in commentsSeongsu Park
fix typo in comments thath -> that Signed-off-by: Seongsu Park <sgsu.park@samsung.com> Link: https://lore.kernel.org/r/20240202013306.883777-1-sgsu.park@samsung.com Signed-off-by: Will Deacon <will@kernel.org>
2024-02-09arm64/signal: Don't assume that TIF_SVE means we saved SVE stateMark Brown
When we are in a syscall we will only save the FPSIMD subset even though the task still has access to the full register set, and on context switch we will only remove TIF_SVE when loading the register state. This means that the signal handling code should not assume that TIF_SVE means that the register state is stored in SVE format, it should instead check the format that was recorded during save. Fixes: 8c845e273104 ("arm64/sve: Leave SVE enabled on syscall if we don't context switch") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240130-arm64-sve-signal-regs-v2-1-9fc6f9502782@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-02-09arm64: rust: Enable Rust support for AArch64Jamie Cunliffe
This commit provides the build flags for Rust for AArch64. The core Rust support already in the kernel does the rest. This enables the PAC ret and BTI options in the Rust build flags to match the options that are used when building C. The Rust samples have been tested with this commit. Signed-off-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com> Acked-by: Will Deacon <will@kernel.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Fabien Parent <fabien.parent@linaro.org> Link: https://lore.kernel.org/r/20231020155056.3495121-3-Jamie.Cunliffe@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-02-09rust: Refactor the build target to allow the use of builtin targetsJamie Cunliffe
Eventually we want all architectures to be using the target as defined by rustc. However currently some architectures can't do that and are using the target.json specification. This puts in place the foundation to allow the use of the builtin target definition or a target.json specification. Signed-off-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20231020155056.3495121-2-Jamie.Cunliffe@arm.com [catalin.marinas@arm.com: squashed loongarch ifneq fix from WANG Rui] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-02-09x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6Aleksander Mazur
The kernel built with MCRUSOE is unbootable on Transmeta Crusoe. It shows the following error message: This kernel requires an i686 CPU, but only detected an i586 CPU. Unable to boot - please use a kernel appropriate for your CPU. Remove MCRUSOE from the condition introduced in commit in Fixes, effectively changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the CPU family given by CPUID. [ bp: Massage commit message. ] Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig") Signed-off-by: Aleksander Mazur <deweloper@wp.pl> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl
2024-02-09s390/extmem: fix virtual vs physical address confusionAlexander Gordeev
Fix virtual vs physical address confusion. This does not fix a bug since virtual and physical address spaces are currently the same. Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/fpu: make use of __uninitialized macroHeiko Carstens
Code sections in s390 specific kernel code which use floating point or vector registers all come with a 520 byte stack variable to save already in use registers, if required. With INIT_STACK_ALL_PATTERN or INIT_STACK_ALL_ZERO enabled this variable will always be initialized on function entry in addition to saving register contents, which contradicts the intention (performance improvement) of such code sections. Therefore provide a DECLARE_KERNEL_FPU_ONSTACK() macro which provides struct kernel_fpu variables with an __uninitialized attribute, and convert all existing code to use this. This way only this specific type of stack variable will not be initialized, regardless of config options. Reviewed-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20240205154844.3757121-3-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/time: make stp_subsys constRicardo B. Marliere
Now that the driver core can properly handle constant struct bus_type, move the stp_subsys variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: "Ricardo B. Marliere" <ricardo@marliere.net> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240204-bus_cleanup-s390_time-v1-1-d2120156982a@marliere.net Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/vdso: drop '-fPIC' from LDFLAGSNathan Chancellor
'-fPIC' as an option to the linker does not do what it seems like it should. With ld.bfd, it is treated as '-f PIC', which does not make sense based on the meaning of '-f': -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table When building with ld.lld (currently under review in a GitHub pull request), it just errors out because '-f' means nothing and neither does '-fPIC': ld.lld: error: unknown argument '-fPIC' '-fPIC' was blindly copied from CFLAGS when the vDSO stopped being linked with '$(CC)', it should not be needed. Remove it to clear up the build failure with ld.lld. Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Link: https://github.com/llvm/llvm-project/pull/75643 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Link: https://lore.kernel.org/r/20240130-s390-vdso-drop-fpic-from-ldflags-v1-1-094ad104fc55@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/mmap: disable mmap alignment when randomize_va_space = 0Sven Schnelle
Stefan reported a test case fail in libc. The test runs with randomize_va_space set to zero, i.e. disabled randomization. Additionally, it runs the program with the dynamic loader. Looking at the failure showed that the heap was placed right before some pages mapped from the binary. This made memory allocation fail after a few allocations. Normally, when address randomization is switched off and the binary is loaded from the dynamic loader, the kernel places the binary below the 128MB top gap. So the address map would look like this: 3fff7fd1000-3fff7fd2000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7fd2000-3fff7ff2000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7ff2000-3fff7ffc000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7ffc000-3fff7ffe000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7ffe000-3fff8000000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff8000000-3fff8021000 rw-p 00000000 00:00 0 [heap] 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] However, commit 1f6b83e5e4d3 ("s390: avoid z13 cache aliasing") introduced a mmap alignment mask of 8MB. With this commit, the memory map now looks like this: 3fff7f80000-3fff7f81000 r--p 00000000 5e:01 1447115 /lib/ld64.so.1 3fff7f81000-3fff7fa1000 r-xp 00001000 5e:01 1447115 /lib/ld64.so.1 3fff7fa1000-3fff7fab000 r--p 00021000 5e:01 1447115 /lib/ld64.so.1 3fff7fab000-3fff7fad000 r--p 0002a000 5e:01 1447115 /lib/ld64.so.1 3fff7fad000-3fff7faf000 rw-p 0002c000 5e:01 1447115 /lib/ld64.so.1 3fff7faf000-3fff7fd0000 rw-p 00000000 00:00 0 [heap] 3fff7fdc000-3fff8000000 rw-p 00000000 00:00 0 3fffffda000-3ffffffb000 rw-p 00000000 00:00 0 [stack] 3ffffffc000-3ffffffe000 r--p 00000000 00:00 0 [vvar] 3ffffffe000-40000000000 r-xp 00000000 00:00 0 [vdso] The reason for this placement is that the elf loader loads the binary to end at mmap_base (0x3fff8000000 on s390). This would result in a start address of 0x3fff7fd1000, but due to the alignment requirement of 8MB, mmap chooses 0x3fff7f80000. This causes a gap between the end of the mapped binary and mmap_base. When the next non-shared and non-file pages are mapped, mmap searches from top to bottom and the first free space it finds is the gap which is now present. This leaves only a few pages for the heap. With enabled address space randomization this doesn't happen because the binary is mapped to a completely different memory area. Fix this by disabling the mmap alignment when address space randomization is disabled. This is in line with what other architectures are doing. Reported-by: Stefan Liebler <stli@linux.ibm.com> Tested-by: Stefan Liebler <stli@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/hypfs_sprp: remove unneeded DMA zone allocationHeiko Carstens
Remove GFP_DMA flag when allocating memory to be used for diagnose 304. Diagnose 304 can access memory beyond the DMA zone. Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/diag: add missing virt_to_phys() translation to diag14()Thomas Richter
diag14() is currently only used by the vmur device driver. The third parameter, called subcommand, determines the type of the first parameter. For some subcommands the value of the first parameter is an address to a memory buffer and needs virtual to physical address conversion. Other subcommands interpret the first parameter is an integer. This doesn't fix a bug since virtual and physical addresses are currently the same. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/time: improve steering precisionSven Schnelle
The common timekeeping code steers the clock by adjusting the multiplier value of the clock. With the current value of 1000 precision is lost when the clock is steered with a userspace daemon. Increase the multiplier and the shift values to increase precision. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/pai_crypto: return proper error code in paicrypt_initThomas Richter
paicrypt_init() return incorrect error code in case the number of PAI crypto counters is too high. Change the return code to -E2BIG. Please merge with d0b0efedc7fe Reported-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-02-09s390/pai: export number of sysfs attribute filesThomas Richter
The number of sysfs files to be exported by the PAI device drivers depends on the hardware version level. Use the value returned by the hardware as the maximum number of counters to be exported in the sysfs attribute tree. Without the fix, older machine generation export counter names based on paiXXXX_ctrnames static array info, which can be inaccurate, as this array could also contain newer counter names in the future. This ensures proper pai counter sysfs attributes for both newer generation and older generation processors. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>