summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-08-25x86/cpu_entry_area: Annotate percpu_setup_exception_stacks() as __initNathan Chancellor1-1/+1
After a recent LLVM change that deduces __cold on functions that only call cold code (such as __init functions), there is a section mismatch warning from percpu_setup_exception_stacks(), which got moved to .text.unlikely. as a result of that optimization: WARNING: modpost: vmlinux: section mismatch in reference: percpu_setup_exception_stacks+0x3a (section: .text.unlikely.) -> cea_map_percpu_pages (section: .init.text) Drop the inline keyword, which does not guarantee inlining, and replace it with __init, as percpu_setup_exception_stacks() is only called from __init code, which clears up the warning. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20240822-x86-percpu_setup_exception_stacks-init-v1-1-57c5921b8209@kernel.org
2024-08-25Merge tag 's390-6.11-4' of ↵Linus Torvalds8-33/+85
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix KASLR base offset to account for symbol offsets in the vmlinux ELF file, preventing tool breakages like the drgn debugger - Fix potential memory corruption of physmem_info during kernel physical address randomization - Fix potential memory corruption due to overlap between the relocated lowcore and identity mapping by correctly reserving lowcore memory - Fix performance regression and avoid randomizing identity mapping base by default - Fix unnecessary delay of AP bus binding complete uevent to prevent startup lag in KVM guests using AP * tag 's390-6.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/boot: Fix KASLR base offset off by __START_KERNEL bytes s390/boot: Avoid possible physmem_info segment corruption s390/ap: Refine AP bus bindings complete processing s390/mm: Pin identity mapping base to zero s390/mm: Prevent lowcore vs identity mapping overlap
2024-08-24arm64: dts: ti: k3-am642-evm: Silence schema warningJan Kiszka1-0/+4
The resolves k3-am642-evm.dtb: adc: 'ti,adc-channels' is a required property from schema $id: http://devicetree.org/schemas/iio/adc/ti,am3359-adc.yaml# As the adc is reserved, thus not used by Linux, this has no practical impact. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/c16521bd55ebed8d1625f11c2ed6fd2c45e8baa5.1723653439.git.jan.kiszka@siemens.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am654-idk: Add Support for MCANFaiz Abbas1-0/+61
There are two MCAN instances present on the am65x SoC [0]. Since there are two CAN transceivers on the IDK application board for AM654 EVM [1], enable m_can0 and m_can1, add the two corresponding CAN transceiver nodes, and set a maximum data rate of 5 Mbps. [0] https://www.ti.com/lit/ds/symlink/am6548.pdf [1] https://www.ti.com/lit/zip/sprr382 Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20240821205414.1706661-1-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am65: Add simple-mfd compatible to SerDes control nodesAndrew Davis1-2/+2
The SerDes control nodes contain both a clock and clock mux, this is a simple MFD. Add this to the compatible string list. Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Closes: https://lore.kernel.org/linux-arm-kernel/cover.1723653439.git.jan.kiszka@siemens.com/ Fixes: da795dc4f2a0 ("arm64: dts: ti: k3-am65: Move SerDes mux nodes under the control node") Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Link: https://lore.kernel.org/r/20240821162337.33774-2-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: am642-phyboard-electra: Add PRU-ICSSG nodesWadim Egorov1-0/+146
The phyBOARD-Electra implements two Ethernet ports utilizing PRUs. Add configuration for both mac ports & PHYs. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240815113212.3720403-1-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am62: Enable CPU freq throttling on thermal alertAlessandro Zini2-0/+38
Enable throttling down the CPU frequency when an alert temperature threshold (lower than the critical threshold) is reached. Signed-off-by: Alessandro Zini <alessandro.zini@siemens.com> Link: https://lore.kernel.org/r/20240814214328.14155-1-alessandro.zini@siemens.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-j722s: Add gpio-reserved-ranges for main_gpio1Jared McArthur1-0/+1
Commit ed07d82f9e3e8 ("arm64: dts: ti: k3-am62p-j722s: Move SoC-specific node properties") introduced the main_gpio1 node and included the ti,ngpio property, but did not include the gpio-reserved-ranges property. As a result, the user could try to access gpios that do not exist. Fix this by introducing the gpio-reserved-ranges property. The non-existent gpios are found in the am67x datasheet [1] in Table 5-27. Depends on patch: dt-bindings: gpio: gpio-davinci: Add the gpio-reserved-ranges property [2] [1] https://www.ti.com/lit/ds/symlink/am67.pdf [2] https://lore.kernel.org/all/20240809154638.394091-2-j-mcarthur@ti.com/ Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Link: https://lore.kernel.org/r/20240809162828.1945821-3-j-mcarthur@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am62p: Add gpio-reserved-ranges for main_gpio1Jared McArthur1-0/+1
Commit 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") introduced the main_gpio1 node and included the ti,ngpio property, but did not include the gpio-reserved-ranges property. As a result, the user could try to access gpios that do not exist. Fix this by introducing the gpio-reserved-ranges property. The non-existent gpios are found in the am62p datasheet [1] in Table 5-24. Depends on patch: dt-bindings: gpio: gpio-davinci: Add the gpio-reserved-ranges property [2] [1] https://www.ti.com/lit/ds/symlink/am62p.pdf [2] https://lore.kernel.org/all/20240809154638.394091-2-j-mcarthur@ti.com/ Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Link: https://lore.kernel.org/r/20240809162828.1945821-2-j-mcarthur@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am68-sk-base-board: Add clklb pin mux for mmc1Bhavya Kapoor1-0/+1
mmc1 is not functional and needs clock loopback so that it can create sampling clock from this for high speed SDIO operations. Thus, add clklb pin mux to get mmc1 working. Fixes: a266c180b398 ("arm64: dts: ti: k3-am68-sk: Add support for AM68 SK base board") Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com> Link: https://lore.kernel.org/r/20240809072231.2931206-1-b-kapoor@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-am642-tqma64xxl-mbax4xxl: add PRU Ethernet supportMatthias Schiffer1-0/+98
Add PRU Ethernet controller and PHY nodes, as it was previously done for the AM64x EVM Device Trees. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20240807121922.3180213-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24arm64: dts: ti: k3-j784s4-evm: Use 4 lanes for PCIe0 on EVMSiddharth Vadapalli1-2/+3
The PCIe0 instance of the PCIe controller on J784S4 SoC supports up to 4 lanes. Additionally, all 4 lanes of PCIe0 can be utilized on J784S4-EVM via SERDES1. Since SERDES1 is not being used by any peripheral apart from PCIe0, use all 4 lanes of SERDES1 for PCIe0. Fixes: 27ce26fe52d4 ("arm64: dts: ti: k3-j784s4-evm: Enable PCIe0 and PCIe1 in RC Mode") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20240720110455.3043327-1-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2024-08-24ARM: dts: microchip: sam9x60: Fix rtc/rtt clocksAlexander Dahl1-2/+2
The RTC and RTT peripherals use the timing domain slow clock (TD_SLCK), sourced from the 32.768 kHz crystal oscillator or slow rc oscillator. The previously used Monitoring domain slow clock (MD_SLCK) is sourced from an internal RC oscillator which is most probably not precise enough for real time clock purposes. Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board") Fixes: 5f6b33f46346 ("ARM: dts: sam9x60: add rtt") Signed-off-by: Alexander Dahl <ada@thorsis.com> Link: https://lore.kernel.org/r/20240821055136.6858-1-ada@thorsis.com [claudiu.beznea: removed () around the last commit description paragraph, removed " in front of "timing domain slow clock", described that TD_SLCK can also be sourced from slow rc oscillator] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-08-24ARM: dts: microchip: sam9x60: Remove additional compatible string from GPIO nodeManikandan Muralidharan1-4/+4
The driver data specific to each pinctrl GPIO bank compatible nodes are not the same and declaring additional compatible string as fallback has no specific purpose, hence, removing the "atmel,at91sam9x5-gpio" compatible from sam9x60 SoC DT. Note: The at91 pinctrl driver uses "atmel,at91rm9200-gpio" compatible string to find the number of active GPIO banks and identify the pinmux nodes.It should used as a constant across all DT for GPIO node banks that uses PIO3 based pinctrl driver Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240814061315.112564-4-manikandan.m@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-08-24ARM: dts: microchip: Remove additional compatible string from PIO3 pinctrl nodesManikandan Muralidharan5-5/+5
The driver data specific to each pinctrl GPIO bank compatible nodes are not the same and declaring additional compatible string as fallback has no specific purpose, hence, removing the additional compatible string from the pinctrl nodes in DT to comply with atmel,at91-pinctrl.txt documentation. Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240814061315.112564-3-manikandan.m@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-08-24ARM: dts: microchip: change to simple-mfd from simple-bus for PIO3 pinumux ↵Manikandan Muralidharan11-11/+11
controller The pinctrl subnodes that define the pin configuration of other devices under PIO3 pinmux controller are not simple memory mapped nodes.Ergo, change simple-bus to simple-mfd. Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240814061315.112564-2-manikandan.m@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-08-24crypto: simd - Do not call crypto_alloc_tfm during registrationHerbert Xu2-2/+2
Algorithm registration is usually carried out during module init, where as little work as possible should be carried out. The SIMD code violated this rule by allocating a tfm, this then triggers a full test of the algorithm which may dead-lock in certain cases. SIMD is only allocating the tfm to get at the alg object, which is in fact already available as it is what we are registering. Use that directly and remove the crypto_alloc_tfm call. Also remove some obsolete and unused SIMD API. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-08-24crypto: x86/sha256 - Add parentheses around macros' single argumentsFangrui Song1-8/+8
The macros FOUR_ROUNDS_AND_SCHED and DO_4ROUNDS rely on an unexpected/undocumented behavior of the GNU assembler, which might change in the future (https://sourceware.org/bugzilla/show_bug.cgi?id=32073). M (1) (2) // 1 arg !? Future: 2 args M 1 + 2 // 1 arg !? Future: 3 args M 1 2 // 2 args Add parentheses around the single arguments to support future GNU assembler and LLVM integrated assembler (when the IsOperator hack from the following link is dropped). Link: https://github.com/llvm/llvm-project/commit/055006475e22014b28a070db1bff41ca15f322f0 Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-08-24Merge tag 'mips-fixes_6.11_1' of ↵Linus Torvalds2-8/+11
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - Set correct timer mode on Loongson64 - Only request r4k clockevent interrupt on one CPU * tag 'mips-fixes_6.11_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed MIPS: Loongson64: Set timer mode in cpu-probe
2024-08-24Merge tag 'arm64-fixes' of ↵Linus Torvalds6-5/+33
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 kvm fixes from Catalin Marinas: - Don't drop references on LPIs that weren't visited by the vgic-debug iterator - Cure lock ordering issue when unregistering vgic redistributors - Fix for misaligned stage-2 mappings when VMs are backed by hugetlb pages - Treat SGI registers as UNDEFINED if a VM hasn't been configured for GICv3 * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 KVM: arm64: Ensure canonical IPA is hugepage-aligned when handling fault KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors KVM: arm64: vgic-debug: Don't put unmarked LPIs
2024-08-23x86/hyperv: use helpers to read control registers in hv_snp_boot_ap()Yosry Ahmed1-3/+3
Use native_read_cr*() helpers to read control registers into vmsa->cr* instead of open-coded assembly. No functional change intended, unless there was a purpose to specifying rax. Signed-off-by: Yosry Ahmed <yosryahmed@google.com> Link: https://lore.kernel.org/r/20240805201247.427982-1-yosryahmed@google.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20240805201247.427982-1-yosryahmed@google.com>
2024-08-23x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()Kees Cook1-1/+6
Modern (fortified) memcpy() prefers to avoid writing (or reading) beyond the end of the addressed destination (or source) struct member: In function ‘fortify_memcpy_chk’, inlined from ‘syscall_get_arguments’ at ./arch/x86/include/asm/syscall.h:85:2, inlined from ‘populate_seccomp_data’ at kernel/seccomp.c:258:2, inlined from ‘__seccomp_filter’ at kernel/seccomp.c:1231:3: ./include/linux/fortify-string.h:580:25: error: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning] 580 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As already done for x86_64 and compat mode, do not use memcpy() to extract syscall arguments from struct pt_regs but rather just perform direct assignments. Binary output differences are negligible, and actually ends up using less stack space: - sub $0x84,%esp + sub $0x6c,%esp and less text size: text data bss dec hex filename 10794 252 0 11046 2b26 gcc-32b/kernel/seccomp.o.stock 10714 252 0 10966 2ad6 gcc-32b/kernel/seccomp.o.after Closes: https://lore.kernel.org/lkml/9b69fb14-df89-4677-9c82-056ea9e706f5@gmail.com/ Reported-by: Mirsad Todorovac <mtodorovac69@gmail.com> Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Mirsad Todorovac <mtodorovac69@gmail.com> Link: https://lore.kernel.org/all/20240708202202.work.477-kees%40kernel.org
2024-08-23irqchip/loongarch-avec: Add AVEC irqchip supportTianyang Zhang4-0/+14
Introduce the advanced extended interrupt controllers (AVECINTC). This feature will allow each core to have 256 independent interrupt vectors and MSI interrupts can be independently routed to any vector on any CPU. The whole topology of irqchips in LoongArch machines looks like this if AVECINTC is supported: +-----+ +-----------------------+ +-------+ | IPI | --> | CPUINTC | <-- | Timer | +-----+ +-----------------------+ +-------+ ^ ^ ^ | | | +---------+ +----------+ +---------+ +-------+ | EIOINTC | | AVECINTC | | LIOINTC | <-- | UARTs | +---------+ +----------+ +---------+ +-------+ ^ ^ | | +---------+ +---------+ | PCH-PIC | | PCH-MSI | +---------+ +---------+ ^ ^ ^ | | | +---------+ +---------+ +---------+ | Devices | | PCH-LPC | | Devices | +---------+ +---------+ +---------+ ^ | +---------+ | Devices | +---------+ Co-developed-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Co-developed-by: Liupu Wang <wangliupu@loongson.cn> Signed-off-by: Liupu Wang <wangliupu@loongson.cn> Co-developed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20240823104337.25577-2-zhangtianyang@loongson.cn
2024-08-23LoongArch: Architectural preparation for AVEC irqchipHuacai Chen8-8/+48
Add architectural preparation for AVEC irqchip, including: 1. CPUCFG feature bits definition for AVEC; 2. Detection of AVEC irqchip in cpu_probe(); 3. New IPI type definition (IPI_CLEAR_VECTOR) for AVEC; 4. Provide arch_probe_nr_irqs() for large NR_IRQS; 5. Other related changes about the number of interrupts. Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20240823103936.25092-2-zhangtianyang@loongson.cn
2024-08-23LoongArch: Move irqchip function prototypes to irq-loongson.hHuacai Chen1-14/+0
Some irqchip functions are only for internal use by irqchip drivers, so move their prototypes from asm/irq.h to drivers/irqchip/irq-loongson.h. All related driver files include the new irq-loongson.h. Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20240823103936.25092-1-zhangtianyang@loongson.cn
2024-08-23arm64: dts: renesas: r9a07g043u: Add DU nodeBiju Das1-0/+25
Add DU node to RZ/G2UL SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240822162320.5084-4-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: white-hawk-cpu-common: Enable PCIe Host ch0Yoshihiro Shimoda1-0/+18
Enable PCIe Host controller channel 0 on R-Car V4H White Hawk boards. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240822004454.1087582-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r8a779g0: Add PCIe Host and Endpoint nodesYoshihiro Shimoda1-0/+134
Add PCIe Host and Endpoint nodes for R-Car V4H (R8A779G0). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240822004454.1087582-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: rzg3s-smarc-som: Enable I2C1 nodeClaudiu Beznea1-0/+5
Enable I2C1 node. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240820101918.2384635-12-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: rzg3s-smarc: Enable I2C0 nodeClaudiu Beznea1-0/+7
Enable I2C0 node. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240820101918.2384635-11-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a08g045: Add I2C nodesClaudiu Beznea1-0/+88
The Renesas RZ/G3S SoC has 4 I2C channels. Add DT nodes for them. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240820101918.2384635-10-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g043u: Add VSPD nodeBiju Das1-0/+13
Add VSPD node to RZ/G2UL SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240805131709.101679-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g043u: Add FCPVD nodeBiju Das1-0/+11
Add FCPVD node to RZ/G2UL SoC DTSI. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240805131709.101679-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizesLad Prabhakar1-2/+2
The RZ/G2L(C) SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU. Fixes: 68a45525297b2 ("arm64: dts: renesas: Add initial DTSI for RZ/G2{L,LC} SoC's") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/20240730122436.350013-5-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizesLad Prabhakar1-2/+2
The RZ/V2L SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU. Fixes: 7c2b8198f4f32 ("arm64: dts: renesas: Add initial DTSI for RZ/V2L SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/20240730122436.350013-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizesLad Prabhakar1-2/+2
The RZ/G2UL SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU. Despite the RZ/G2UL SoC being single-core, it has two instances of GICR. Fixes: cf40c9689e510 ("arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/20240730122436.350013-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizesLad Prabhakar1-2/+2
The RZ/G3S SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU. Despite the RZ/G3S SoC being single-core, it has two instances of GICR. Fixes: e20396d65b959 ("arm64: dts: renesas: Add initial DTSI for RZ/G3S SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/20240730122436.350013-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r9a07g0{43,44,54}: Move regulator-vbus device nodeBiju Das4-3/+12
Move regulator-vbus device node from common to the usbphy-ctrl device node of the individual SoC dtsi's as it embeds the vbus regulator. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240715140705.334183-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: white-hawk-single: Wire-up Ethernet TSNNiklas Söderlund1-0/+51
On the V4H White Hawk Single board as opposed to the Quad board the Ethernet TSN is wired up to a PHY (Marvel 88Q2110/QFN40). Wire up the connection and enable the TSN0. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240701145012.2342868-3-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: dts: renesas: r8a779g0: R-Car Ethernet TSN supportNiklas Söderlund1-0/+14
Add Ethernet TSN support for R-Car V4H. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240701145012.2342868-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2024-08-23arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI firstDouglas Anderson1-63/+97
When testing hard lockup handling on my sc7180-trogdor-lazor device with pseudo-NMI enabled, with serial console enabled and with kgdb disabled, I found that the stack crawls printed to the serial console ended up as a jumbled mess. After rebooting, the pstore-based console looked fine though. Also, enabling kgdb to trap the panic made the console look fine and avoided the mess. After a bit of tracking down, I came to the conclusion that this was what was happening: 1. The panic path was stopping all other CPUs with panic_other_cpus_shutdown(). 2. At least one of those other CPUs was in the middle of printing to the serial console and holding the console port's lock, which is grabbed with "irqsave". ...but since we were stopping with an NMI we didn't care about the "irqsave" and interrupted anyway. 3. Since we stopped the CPU while it was holding the lock it would never release it. 4. All future calls to output to the console would end up failing to get the lock in qcom_geni_serial_console_write(). This isn't _totally_ unexpected at panic time but it's a code path that's not well tested, hard to get right, and apparently doesn't work terribly well on the Qualcomm geni serial driver. The Qualcomm geni serial driver was fixed to be a bit better in commit 9e957a155005 ("serial: qcom-geni: Don't cancel/abort if we can't get the port lock") but it's nice not to get into this situation in the first place. Taking a page from what x86 appears to do in native_stop_other_cpus(), do this: 1. First, try to stop other CPUs with a normal IPI and wait a second. This gives them a chance to leave critical sections. 2. If CPUs fail to stop then retry with an NMI, but give a much lower timeout since there's no good reason for a CPU not to react quickly to a NMI. This works well and avoids the corrupted console and (presumably) could help avoid other similar issues. In order to do this, we need to do a little re-organization of our IPIs since we don't have any more free IDs. Do what was suggested in previous conversations and combine "stop" and "crash stop". That frees up an IPI so now we can have a "stop" and "stop NMI". In order to do this we also need a slight change in the way we keep track of which CPUs still need to be stopped. We need to know specifically which CPUs haven't stopped yet when we fall back to NMI but in the "crash stop" case the "cpu_online_mask" isn't updated as CPUs go down. This is why that code path had an atomic of the number of CPUs left. Solve this by also updating the "cpu_online_mask" for crash stops. All of the above lets us combine the logic for "stop" and "crash stop" code, which appeared to have a bunch of arbitrary implementation differences. Aside from the above change where we try a normal IPI and then an NMI, the combined function has a few subtle differences: * In the normal smp_send_stop(), if we fail to stop one or more CPUs then we won't include the current CPU (the one running smp_send_stop()) in the error message. * In crash_smp_send_stop(), if we fail to stop some CPUs we'll print the CPUs that we failed to stop instead of printing all _but_ the current running CPU. * In crash_smp_send_stop(), we will now only print "SMP: stopping secondary CPUs" if (system_state <= SYSTEM_RUNNING). Fixes: d7402513c935 ("arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20240821145353.v3.1.Id4817adef610302554b8aa42b090d57270dc119c@changeid Signed-off-by: Will Deacon <will@kernel.org>
2024-08-23Merge tag 'kvmarm-fixes-6.11-2' of ↵Catalin Marinas18-38/+72
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into for-next/fixes KVM/arm64 fixes for 6.11, round #2 - Don't drop references on LPIs that weren't visited by the vgic-debug iterator - Cure lock ordering issue when unregistering vgic redistributors - Fix for misaligned stage-2 mappings when VMs are backed by hugetlb pages - Treat SGI registers as UNDEFINED if a VM hasn't been configured for GICv3 * tag 'kvmarm-fixes-6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 KVM: arm64: Ensure canonical IPA is hugepage-aligned when handling fault KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors KVM: arm64: vgic-debug: Don't put unmarked LPIs KVM: arm64: vgic: Hold config_lock while tearing down a CPU interface KVM: selftests: arm64: Correct feature test for S1PIE in get-reg-list KVM: arm64: Tidying up PAuth code in KVM KVM: arm64: vgic-debug: Exit the iterator properly w/o LPI KVM: arm64: Enforce dependency on an ARMv8.4-aware toolchain docs: KVM: Fix register ID of SPSR_FIQ KVM: arm64: vgic: fix unexpected unlock sparse warnings KVM: arm64: fix kdoc warnings in W=1 builds KVM: arm64: fix override-init warnings in W=1 builds KVM: arm64: free kvm->arch.nested_mmus with kvfree()
2024-08-23arm64: dts: exynosautov920: add initial CMU clock nodes in ExynosAuto v920Sunyeal Hong1-13/+27
Add cmu_top, cmu_peric0 clock nodes and switch USI clocks instead of dummy fixed-rate-clock. Signed-off-by: Sunyeal Hong <sunyeal.hong@samsung.com> Link: https://lore.kernel.org/r/20240821232652.1077701-3-sunyeal.hong@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-08-22KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM support is missingRavi Bangoria1-0/+3
If host supports Bus Lock Detect, KVM advertises it to guests even if SVM support is absent. Additionally, guest wouldn't be able to use it despite guest CPUID bit being set. Fix it by unconditionally clearing the feature bit in KVM cpu capability. Reported-by: Jim Mattson <jmattson@google.com> Closes: https://lore.kernel.org/r/CALMp9eRet6+v8Y1Q-i6mqPm4hUow_kJNhmVHfOV8tMfuSS=tVg@mail.gmail.com Fixes: 76ea438b4afc ("KVM: X86: Expose bus lock debug exception to guest") Cc: stable@vger.kernel.org Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Reviewed-by: Jim Mattson <jmattson@google.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/20240808062937.1149-4-ravi.bangoria@amd.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Suppress userspace access failures on unsupported, "emulated" MSRsSean Christopherson1-3/+8
Extend KVM's suppression of userspace MSR access failures to MSRs that KVM reports as emulated, but are ultimately unsupported, e.g. if the VMX MSRs are emulated by KVM, but are unsupported given the vCPU model. Suggested-by: Weijiang Yang <weijiang.yang@intel.com> Reviewed-by: Weijiang Yang <weijiang.yang@intel.com> Link: https://lore.kernel.org/r/20240802181935.292540-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Suppress failures on userspace access to advertised, unsupported MSRsSean Christopherson1-18/+9
Extend KVM's suppression of failures due to a userspace access to an unsupported, but advertised as a "to save" MSR to all MSRs, not just those that happen to reach the default case statements in kvm_get_msr_common() and kvm_set_msr_common(). KVM's soon-to-be-established ABI is that if an MSR is advertised to userspace, then userspace is allowed to read the MSR, and write back the value that was read, i.e. why an MSR is unsupported doesn't change KVM's ABI. Practically speaking, this is very nearly a nop, as the only other paths that return KVM_MSR_RET_UNSUPPORTED are {svm,vmx}_get_feature_msr(), and it's unlikely, though not impossible, that userspace is using KVM_GET_MSRS on unsupported MSRs. The primary goal of moving the suppression to common code is to allow returning KVM_MSR_RET_UNSUPPORTED as appropriate throughout KVM, without having to manually handle the "is userspace accessing an advertised" waiver. I.e. this will allow formalizing KVM's ABI without incurring a high maintenance cost. Link: https://lore.kernel.org/r/20240802181935.292540-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Hoist x86.c's global msr_* variables up above kvm_do_msr_access()Sean Christopherson1-184/+184
Move the definitions of the various MSR arrays above kvm_do_msr_access() so that kvm_do_msr_access() can query the arrays when handling failures, e.g. to squash errors if userspace tries to read an MSR that isn't fully supported, but that KVM advertised as being an MSR-to-save. No functional change intended. Link: https://lore.kernel.org/r/20240802181935.292540-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Funnel all fancy MSR return value handling into a common helperSean Christopherson1-42/+42
Add a common helper, kvm_do_msr_access(), to invoke the "leaf" APIs that are type and access specific, and more importantly to handle errors that are returned from the leaf APIs. I.e. turn kvm_msr_ignored_check() from a a helper that is called on an error, into a trampoline that detects errors *and* applies relevant side effects, e.g. logging unimplemented accesses. Because the leaf APIs are used for guest accesses, userspace accesses, and KVM accesses, and because KVM supports restricting access to MSRs from userspace via filters, the error handling is subtly non-trivial. E.g. KVM has had at least one bug escape due to making each "outer" function handle errors. See commit 3376ca3f1a20 ("KVM: x86: Fix KVM_GET_MSRS stack info leak"). Link: https://lore.kernel.org/r/20240802181935.292540-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Refactor kvm_get_feature_msr() to avoid struct kvm_msr_entrySean Christopherson1-16/+13
Refactor kvm_get_feature_msr() to take the components of kvm_msr_entry as separate parameters, along with a vCPU pointer, i.e. to give it the same prototype as kvm_{g,s}et_msr_ignored_check(). This will allow using a common inner helper for handling accesses to "regular" and feature MSRs. No functional change intended. Link: https://lore.kernel.org/r/20240802181935.292540-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-08-22KVM: x86: Rename get_msr_feature() APIs to get_feature_msr()Sean Christopherson7-14/+14
Rename all APIs related to feature MSRs from get_msr_feature() to get_feature_msr(). The APIs get "feature MSRs", not "MSR features". And unlike kvm_{g,s}et_msr_common(), the "feature" adjective doesn't describe the helper itself. No functional change intended. Link: https://lore.kernel.org/r/20240802181935.292540-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>