summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-10-14ARM: dts: renesas: iwg22d-sodimm: Use interrupts-extended for port expanderGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupt. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/835b5e851939f6fa2c9567d6850a7e0c2574c1c7.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for video decodersGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/a8610814e31d0562732672f11d2be1404322121a.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for touchpanelsGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/d081d986e3a2b695bc27dbe00aa0fb244a22ffdf.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for PMICsGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/934b9b9992dacd72dbad0f5433728aac292a3cfc.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for HDMI bridgesGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/850317c7818b100f9afe026e80b6d685affe81a0.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for Ethernet PHYsGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/623645456e7636f43150a70f8603114b26304818.1728045620.git.geert+renesas@glider.be
2024-10-14ARM: dts: renesas: Use interrupts-extended for Ethernet MACsGeert Uytterhoeven
Use the more concise interrupts-extended property to fully describe the interrupts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/f51de53cb003f850751e13fdbddea64ad942ee7b.1728045620.git.geert+renesas@glider.be
2024-10-13cfi: fix conditions for HAVE_CFI_ICALL_NORMALIZE_INTEGERSAlice Ryhl
The HAVE_CFI_ICALL_NORMALIZE_INTEGERS option has some tricky conditions when KASAN or GCOV are turned on, as in that case we need some clang and rustc fixes [1][2] to avoid boot failures. The intent with the current setup is that you should be able to override the check and turn on the option if your clang/rustc has the fix. However, this override does not work in practice. Thus, use the new RUSTC_LLVM_VERSION to correctly implement the check for whether the fix is available. Additionally, remove KASAN_HW_TAGS from the list of incompatible options. The CFI_ICALL_NORMALIZE_INTEGERS option is incompatible with KASAN because LLVM will emit some constructors when using KASAN that are assigned incorrect CFI tags. These constructors are emitted due to use of -fsanitize=kernel-address or -fsanitize=kernel-hwaddress that are respectively passed when KASAN_GENERIC or KASAN_SW_TAGS are enabled. However, the KASAN_HW_TAGS option relies on hardware support for MTE instead and does not pass either flag. (Note also that KASAN_HW_TAGS does not `select CONSTRUCTORS`.) Link: https://github.com/llvm/llvm-project/pull/104826 [1] Link: https://github.com/rust-lang/rust/pull/129373 [2] Fixes: 4c66f8307ac0 ("cfi: encode cfi normalized integers + kasan/gcov bug in Kconfig") Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20241010-icall-detect-vers-v1-2-8f114956aa88@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-13ARM: dts: microchip: Rename LED sub nodes nameAndrei Simion
dtbs_check warnings: leds: 'd[0-9]', 'ds[0-9]' do not match any of the regexes : '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' leds: 'red', 'green', 'blue' do not match any of regexes : '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' Rename the led sub nodes according to devicetree specification and leds-gpio.yaml and for aks-cdu add label property and use the old node name as value to stay stable and avoid breaking the userspace applications that depend on those paths. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241002123010.111028-4-andrei.simion@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: Rename the pmic nodeAndrei Simion
Rename the pmic node according to the devicetree specification. Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241002123010.111028-3-andrei.simion@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: Rename the eeprom nodenameAndrei Simion
Align the eeprom nodename according to devicetree specification and at24.yaml Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20241002123010.111028-2-andrei.simion@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: configs: at91: enable PAC1934 driver as moduleMihai Sain
Enable PAC1934 driver and build as module. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20240923064932.5797-6-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: sama7g5ek: Add power monitor supportMihai Sain
Add PAC1934 support in order to monitor the board power consumption. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20240923064932.5797-5-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: sama7g54_curiosity: Add power monitor supportMihai Sain
Add PAC1934 support in order to monitor the board power consumption. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20240923064932.5797-4-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: sama5d2_icp: Add power monitor supportMihai Sain
Add PAC1934 support in order to monitor the board power consumption. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20240923064932.5797-3-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: sam9x60ek: Add power monitor supportMihai Sain
Add PAC1934 support in order to monitor the board power consumption. Signed-off-by: Mihai Sain <mihai.sain@microchip.com> Link: https://lore.kernel.org/r/20240923064932.5797-2-mihai.sain@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: Unify rng node namesAlexander Dahl
Using a generic name common over different platforms and matching the recent atmel rng binding now. Signed-off-by: Alexander Dahl <ada@thorsis.com> Suggested-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240917072710.125435-3-ada@thorsis.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: Add trng labels for all at91 SoCsAlexander Dahl
SAM9X60 and SAMA7G5 already have those labels. Add it for the other SoC families so it can be referenced in board files. Signed-off-by: Alexander Dahl <ada@thorsis.com> Link: https://lore.kernel.org/r/20240917072710.125435-2-ada@thorsis.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-13ARM: dts: microchip: sam9x60: Add missing property atmel,usart-modeAndrei Simion
Add the atmel,usart-mode property to the UART nodes. This ensures compliance with the atmel,at91-usart.yaml schema and resolves the errors below: serial@200: $nodename:0: 'serial@200' does not match '^spi(@.*|-([0-9]|[1-9][0-9]+))?$' serial@200: atmel,use-dma-rx: False schema does not allow True serial@200: atmel,use-dma-tx: False schema does not allow True serial@200: atmel,fifo-size: False schema does not allow [[16]] These errors indicate that the property atmel,usart-mode = <AT91_USART_MODE_SERIAL> is missing for UART nodes 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, and 12. Fixes: 99c808335877 ("ARM: dts: at91: sam9x60: Add missing flexcom definitions") Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20240912093307.40488-1-andrei.simion@microchip.com [claudiu.beznea: move the atmel,usart-mode close to vendor specific properties to cope with DTS coding style] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-10-12Merge tag 'powerpc-6.12-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fix from Michael Ellerman: - Fix crash in memcpy on 8xx due to dcbz workaround since recent changes Thanks to Christophe Leroy. * tag 'powerpc-6.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/8xx: Fix kernel DTLB miss on dcbz
2024-10-13arm64: dts: ti: Add support for J742S2 EVM boardManorit Chawdhry
J742S2 EVM board is designed for TI J742S2 SoC. It supports the following interfaces: * 16 GB DDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode * x1 Input Audio Jack, x1 Output Audio Jack * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port * x1 4L PCIe connector * x1 UHS-1 capable micro-SD card slot * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, UFS flash. * x6 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * x1 GESI expander, x2 Display connector * x1 15-pin CSI header * x6 MCAN instances Link: https://www.ti.com/lit/ug/sprujd8/sprujd8.pdf (EVM user guide) Link: https://www.ti.com/lit/zip/SPAC001 (Schematics) Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Link: https://lore.kernel.org/r/20240902-b4-upstream-j742s2-v6-5-6a7aa2736797@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-10-13arm64: dts: ti: Introduce J742S2 SoC familyManorit Chawdhry
This device is a subset of J784S4 and shares the same memory map and thus the nodes are being reused from J784S4 to avoid duplication. Here are some of the salient features of the J742S2 automotive grade application processor: The J742S2 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications. Some changes that this devices has from J784S4 are: * 4x Cortex-A72 vs 8x Cortex-A72 * 3x C7x DSP vs 4x C7x DSP * 4 port ethernet switch vs 8 port ethernet switch ( Refer Table 2-1 for Device comparison with J7AHP ) Link: https://www.ti.com/lit/pdf/spruje3 (TRM) Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Link: https://lore.kernel.org/r/20240902-b4-upstream-j742s2-v6-4-6a7aa2736797@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-10-13arm64: dts: ti: Refactor J784s4-evm to a common fileManorit Chawdhry
Refactor J784s4-evm to a common file which uses the superset device to allow reuse in j742s2-evm which uses the subset part. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20240902-b4-upstream-j742s2-v6-2-6a7aa2736797@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-10-13arm64: dts: ti: Refactor J784s4 SoC files to a common fileManorit Chawdhry
Refactor J784s4 SoC files to a common file which uses the superset device to allow reuse in j742s2-evm which uses the subset part. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20240902-b4-upstream-j742s2-v6-1-6a7aa2736797@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2024-10-11Merge tag 'for-linus-6.12a-rc3-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "A fix for topology information of Xen PV guests" * tag 'for-linus-6.12a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE
2024-10-11x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode loadJohn Allen
Commit f69759be251d ("x86/CPU/AMD: Move Zenbleed check to the Zen2 init function") causes a bit in the DE_CFG MSR to get set erroneously after a microcode late load. The microcode late load path calls into amd_check_microcode() and subsequently zen2_zenbleed_check(). Since the above commit removes the cpu_has_amd_erratum() call from zen2_zenbleed_check(), this will cause all non-Zen2 CPUs to go through the function and set the bit in the DE_CFG MSR. Call into the Zenbleed fix path on Zen2 CPUs only. [ bp: Massage commit message, use cpu_feature_enabled(). ] Fixes: f69759be251d ("x86/CPU/AMD: Move Zenbleed check to the Zen2 init function") Signed-off-by: John Allen <john.allen@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240923164404.27227-1-john.allen@amd.com
2024-10-11KVM: arm64: Don't eagerly teardown the vgic on init errorMarc Zyngier
As there is very little ordering in the KVM API, userspace can instanciate a half-baked GIC (missing its memory map, for example) at almost any time. This means that, with the right timing, a thread running vcpu-0 can enter the kernel without a GIC configured and get a GIC created behind its back by another thread. Amusingly, it will pick up that GIC and start messing with the data structures without the GIC having been fully initialised. Similarly, a thread running vcpu-1 can enter the kernel, and try to init the GIC that was previously created. Since this GIC isn't properly configured (no memory map), it fails to correctly initialise. And that's the point where we decide to teardown the GIC, freeing all its resources. Behind vcpu-0's back. Things stop pretty abruptly, with a variety of symptoms. Clearly, this isn't good, we should be a bit more careful about this. It is obvious that this guest is not viable, as it is missing some important part of its configuration. So instead of trying to tear bits of it down, let's just mark it as *dead*. It means that any further interaction from userspace will result in -EIO. The memory will be released on the "normal" path, when userspace gives up. Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko <glider@google.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241009183603.3221824-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2024-10-11eth: remove the DLink/Sundance (ST201) driverJakub Kicinski
Konstantin reports the maintainer's address bounces. There is no other maintainer and the driver is quite old. There is a good chance nobody is using this driver any more. Let's try to remove it completely, we can revert it back in if someone complains. Link: https://lore.kernel.org/20240925-bizarre-earwig-from-pluto-1484aa@lemu/ Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Denis Kirjanov <dkirjanov@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-10-11Merge tag 'arm-soc/for-6.12/devicetree-fixes' of ↵Arnd Bergmann
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for 6.12, please pull the following: - Florian fixed the HDMI gpio pin which is connected to GPIO pin 0, not 1 * tag 'arm-soc/for-6.12/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin Link: https://lore.kernel.org/r/20241008220440.23182-1-florian.fainelli@broadcom.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-10-11powerpc/8xx: Fix kernel DTLB miss on dcbzChristophe Leroy
Following OOPS is encountered while loading test_bpf module on powerpc 8xx: [ 218.835567] BUG: Unable to handle kernel data access on write at 0xcb000000 [ 218.842473] Faulting instruction address: 0xc0017a80 [ 218.847451] Oops: Kernel access of bad area, sig: 11 [#1] [ 218.852854] BE PAGE_SIZE=16K PREEMPT CMPC885 [ 218.857207] SAF3000 DIE NOTIFICATION [ 218.860713] Modules linked in: test_bpf(+) test_module [ 218.865867] CPU: 0 UID: 0 PID: 527 Comm: insmod Not tainted 6.11.0-s3k-dev-09856-g3de3d71ae2e6-dirty #1280 [ 218.875546] Hardware name: MIAE 8xx 0x500000 CMPC885 [ 218.880521] NIP: c0017a80 LR: beab859c CTR: 000101d4 [ 218.885584] REGS: cac2bc90 TRAP: 0300 Not tainted (6.11.0-s3k-dev-09856-g3de3d71ae2e6-dirty) [ 218.894308] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 55005555 XER: a0007100 [ 218.901290] DAR: cb000000 DSISR: c2000000 [ 218.901290] GPR00: 000185d1 cac2bd50 c21b9580 caf7c030 c3883fcc 00000008 cafffffc 00000000 [ 218.901290] GPR08: 00040000 18300000 20000000 00000004 99005555 100d815e ca669d08 00000369 [ 218.901290] GPR16: ca730000 00000000 ca2c004c 00000000 00000000 0000035d 00000311 00000369 [ 218.901290] GPR24: ca732240 00000001 00030ba3 c3800000 00000000 00185d48 caf7c000 ca2c004c [ 218.941087] NIP [c0017a80] memcpy+0x88/0xec [ 218.945277] LR [beab859c] test_bpf_init+0x22c/0x3c90 [test_bpf] [ 218.951476] Call Trace: [ 218.953916] [cac2bd50] [beab8570] test_bpf_init+0x200/0x3c90 [test_bpf] (unreliable) [ 218.962034] [cac2bde0] [c0004c04] do_one_initcall+0x4c/0x1fc [ 218.967706] [cac2be40] [c00a2ec4] do_init_module+0x68/0x360 [ 218.973292] [cac2be60] [c00a5194] init_module_from_file+0x8c/0xc0 [ 218.979401] [cac2bed0] [c00a5568] sys_finit_module+0x250/0x3f0 [ 218.985248] [cac2bf20] [c000e390] system_call_exception+0x8c/0x15c [ 218.991444] [cac2bf30] [c00120a8] ret_from_syscall+0x0/0x28 This happens in the main loop of memcpy() ==> c0017a80: 7c 0b 37 ec dcbz r11,r6 c0017a84: 80 e4 00 04 lwz r7,4(r4) c0017a88: 81 04 00 08 lwz r8,8(r4) c0017a8c: 81 24 00 0c lwz r9,12(r4) c0017a90: 85 44 00 10 lwzu r10,16(r4) c0017a94: 90 e6 00 04 stw r7,4(r6) c0017a98: 91 06 00 08 stw r8,8(r6) c0017a9c: 91 26 00 0c stw r9,12(r6) c0017aa0: 95 46 00 10 stwu r10,16(r6) c0017aa4: 42 00 ff dc bdnz c0017a80 <memcpy+0x88> Commit ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") relies on re-reading DAR register to know if an error is due to a missing copy of a PMD entry in task's PGDIR, allthough DAR was already read in the exception prolog and copied into thread struct. This is because is it done very early in the exception and there are not enough registers available to keep a pointer to thread struct. However, dcbz instruction is buggy and doesn't update DAR register on fault. That is detected and generates a call to FixupDAR workaround which updates DAR copy in thread struct but doesn't fix DAR register. Let's fix DAR in addition to the update of DAR copy in thread struct. Fixes: ac9f97ff8b32 ("powerpc/8xx: Inconditionally use task PGDIR in DTLB misses") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/2b851399bd87e81c6ccb87ea3a7a6b32c7aa04d7.1728118396.git.christophe.leroy@csgroup.eu
2024-10-10ftrace: Make ftrace_regs abstract from direct useSteven Rostedt
ftrace_regs was created to hold registers that store information to save function parameters, return value and stack. Since it is a subset of pt_regs, it should only be used by its accessor functions. But because pt_regs can easily be taken from ftrace_regs (on most archs), it is tempting to use it directly. But when running on other architectures, it may fail to build or worse, build but crash the kernel! Instead, make struct ftrace_regs an empty structure and have the architectures define __arch_ftrace_regs and all the accessor functions will typecast to it to get to the actual fields. This will help avoid usage of ftrace_regs directly. Link: https://lore.kernel.org/all/20241007171027.629bdafd@gandalf.local.home/ Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org> Cc: "x86@kernel.org" <x86@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: WANG Xuerui <kernel@xen0n.name> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Naveen N Rao <naveen@kernel.org> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/20241008230628.958778821@goodmis.org Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390 Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-10-10arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plusHeiko Stuebner
num-slots was not part of the dw-mmc binding and the last slipage of one of them seeping in from the vendor kernel was removed way back in 2017. Somehow the nanopi-r2s-plus managed to smuggle another on in the kernel, so remove that as well. Fixes: b8c028782922 ("arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus") Cc: Sergey Bostandzhyan <jin@mediatomb.cc> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-9-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: Fix LED triggers on rk3308-roc-ccHeiko Stuebner
There are two LEDs on the board, power and user events. Currently both are assigned undocumented IR(-remote) triggers that are probably only part of the vendor-kernel. To make dtbs check happier, assign the power-led to a generic default-on trigger and the user led to the documented rc-feedback trigger that should mostly match its current usage. Fixes: 4403e1237be3 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc") Cc: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-8-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.12-rc3). No conflicts and no adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-10arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lionHeiko Stuebner
All Theobroma boards use a ti,amc6821 as fan controller. It normally runs in an automatically controlled way and while it may be possible to use it as part of a dt-based thermal management, this is not yet specified in the binding, nor implemented in any kernel. Newer boards already don't contain that #cooling-cells property, but older ones do. So remove them for now, they can be re-added if thermal integration gets implemented in the future. There are two further occurences in v6.12-rc in px30-ringneck and rk3399-puma, but those already get removed by the i2c-mux conversion scheduled for 6.13 . As the undocumented property is in the kernel so long, I opted for not causing extra merge conflicts between 6.12 and 6.13 Fixes: d99a02bcfa81 ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM") Cc: Quentin Schulz <quentin.schulz@theobroma-systems.com> Cc: Klaus Goger <klaus.goger@theobroma-systems.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-7-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: Remove undocumented supports-emmc propertyHeiko Stuebner
supports-emmc is an undocumented property that slipped into the mainline kernel devicetree for some boards. Drop it. Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Cc: Quentin Schulz <quentin.schulz@theobroma-systems.com> Fixes: b8c028782922 ("arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus") Cc: Sergey Bostandzhyan <jin@mediatomb.cc> Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1") Cc: Wenhao Cui <lasstp5011@gmail.com> Fixes: cdf46cdbabfc ("arm64: dts: rockchip: Add dts for EmbedFire rk3568 LubanCat 2") Cc: Andy Yan <andyshrk@163.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-6-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: Fix bluetooth properties on Rock960 boardsHeiko Stuebner
The expected clock-name is different, and extclk also is deprecated in favor of txco for clocks that are not crystals. So fix it to match the binding. Fixes: c72235c288c8 ("arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards") Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-5-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demoHeiko Stuebner
The expected clock-name is different, and extclk also is deprecated in favor of txco for clocks that are not crystals. The wakeup gpio properties are named differently too, when changing from vendor-tree to mainline. So fix those to match the binding. Fixes: 2e0537b16b25 ("arm64: dts: rockchip: Add dts for rockchip rk3566 box demo board") Cc: Andy Yan <andyshrk@163.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-4-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: Drop regulator-init-microvolt from two boardsHeiko Stuebner
rk3568-roc-pc and rk3588-toybrick-x0 re-introduced this property despite previous patches removing older instances already. regulator-init-microvolt is not part of any regulator binding and is only used in the Rockchip vendor kernel. So drop it. It is used by u-boot in some places to setup initial regulator-state, but that should happen in the existing -u-boot devicetree additions. Fixes: 007b4bb47f44 ("arm64: dts: rockchip: add dts for Firefly Station P2 aka rk3568-roc-pc") Cc: Furkan Kardame <f.kardame@manjaro.org> Fixes: 8ffe365f8dc7 ("arm64: dts: rockchip: Add devicetree support for TB-RK3588X board") Cc: Elon Zhang <zhangzj@rock-chips.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-3-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/vHeiko Stuebner
We want to control pins, not beer mugs, so rename pintctrl-names to the expected pinctrl-names. This was not affecting functionality, because the i2c2 controller already had a set of pinctrl properties. Fixes: 523adb553573 ("arm64: dts: rockchip: add Anbernic RG353P and RG503") Fixes: 1e141cf12726 ("arm64: dts: rockchip: add Anbernic RG353V and RG353VS") Cc: Chris Morgan <macromorgan@hotmail.com> Acked-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-2-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-10s390/pci: Expose FIDPARM attribute in sysfsNiklas Schnelle
This attribute will be used to communicate function type specific firmware controlled flag bits. Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/cpum_cf: Correct typo CYLCEAntonia Jonas
Signed-off-by: Antonia Jonas <antonia@toertel.de> Link: https://lore.kernel.org/r/20241003115648.26188-1-antonia@toertel.de Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/facilities: Fix warning about shadow of global variableGerd Bayer
Compiling the kernel with clang W=2 produces a warning that the parameter declarations in some routines would shadow the definition of the global variable stfle_fac_list. Address this warning by renaming the parameters to fac_list. Fixes: 17e89e1340a3 ("s390/facilities: move stfl information from lowcore to global data") Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/pci: Switch over to sysfs_emitGerd Bayer
Per Documentation/filesystems/sysfs.rst, sysfs_emit() is preferred over sprintf for presenting attributes to user space. Convert over two left-over uses in the s390 PCI code. Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/cpum_sf: Set bit PMU_F_ENABLED enabled after lpp() invocationThomas Richter
Set PMU enabled bit after lpp() call. This ensures the proper task PID is loaded by the llp instruction into Program Parameter register from where it is copied to each sampling data buffer (SDB) sample entry after the sampling was enabled. The barrier() instruction is not needed as cpumsf_pmu_enable() changes a CPU specific variable. Only the CPU that task is running on changes structure members. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/pci: Ignore RID for isolated VFsNiklas Schnelle
Ensure that VFs used in isolation, that is with their parent PF not visible to the configuration but with their RID exposed, are treated compatibly with existing isolated VF use cases without exposed RID including RoCE Express VFs. This allows creating configurations where one LPAR manages PFs while their child VFs are used by other LPARs. This gives the LPAR managing the PFs a role analogous to that of the hypervisor in a typical use case of passing child VFs to guests. Instead of creating a multifunction struct zpci_bus whenever a PCI function with RID exposed is discovered only create such a bus for configured physical functions and only consider multifunction busses when searching for an existing bus. Additionally only set zdev->devfn to the devfn part of the RID once the function is added to a multifunction bus. This also fixes probing of more than 7 such isolated VFs from the same physical bus. This is because common PCI code in pci_scan_slot() only looks for more functions when pdev->multifunction is set which somewhat counter intutively is not the case for VFs. Note that PFs are looked at before their child VFs is guaranteed because we sort the zpci_list by RID ascending. Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/pci: Use topology ID for multi-function devicesNiklas Schnelle
The newly introduced topology ID (TID) field in the CLP Query PCI Function explicitly identifies groups of PCI functions whose RIDs belong to the same (sub-)topology. When available use the TID instead of the PCHID to match zPCI busses/domains for multi-function devices. Note that currently only a single PCI bus per TID is supported. This change is required because in future machines the PCHID will not identify a PCI card but a specific port in the case of some multi-port NICs while from a PCI point of view the entire card is a subtopology. Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10s390/pci: Sort PCI functions prior to creating virtual bussesNiklas Schnelle
Instead of relying on the observed but not architected firmware behavior that PCI functions from the same card are listed in ascending RID order in clp_list_pci() ensure this by sorting. To allow for sorting separate the initial clp_list_pci() and creation of the virtual PCI busses. Note that fundamentally in our per-PCI function hotplug design non RID order of discovery is still possible. For example when the two PFs of a two port NIC are hotplugged after initial boot and in descending RID order. In this case the virtual PCI bus would be created by the second PF using that PF's UID as domain number instead of that of the first PF. Thus the domain number would then change from the UID of the second PF to that of the first PF on reboot but there is really nothing we can do about that since changing domain numbers at runtime seems even worse. This only impacts the domain number as the RIDs are consistent and thus even with just the second PF visible it will show up in the correct position on the virtual bus. Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10KVM: s390: Change virtual to physical address access in diag 0x258 handlerMichael Mueller
The parameters for the diag 0x258 are real addresses, not virtual, but KVM was using them as virtual addresses. This only happened to work, since the Linux kernel as a guest used to have a 1:1 mapping for physical vs virtual addresses. Fix KVM so that it correctly uses the addresses as real addresses. Cc: stable@vger.kernel.org Fixes: 8ae04b8f500b ("KVM: s390: Guest's memory access functions get access registers") Suggested-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Michael Mueller <mimu@linux.ibm.com> Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20240917151904.74314-3-nrb@linux.ibm.com Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-10-10KVM: s390: gaccess: Check if guest address is in memslotNico Boehr
Previously, access_guest_page() did not check whether the given guest address is inside of a memslot. This is not a problem, since kvm_write_guest_page/kvm_read_guest_page return -EFAULT in this case. However, -EFAULT is also returned when copy_to/from_user fails. When emulating a guest instruction, the address being outside a memslot usually means that an addressing exception should be injected into the guest. Failure in copy_to/from_user however indicates that something is wrong in userspace and hence should be handled there. To be able to distinguish these two cases, return PGM_ADDRESSING in access_guest_page() when the guest address is outside guest memory. In access_guest_real(), populate vcpu->arch.pgm.code such that kvm_s390_inject_prog_cond() can be used in the caller for injecting into the guest (if applicable). Since this adds a new return value to access_guest_page(), we need to make sure that other callers are not confused by the new positive return value. There are the following users of access_guest_page(): - access_guest_with_key() does the checking itself (in guest_range_to_gpas()), so this case should never happen. Even if, the handling is set up properly. - access_guest_real() just passes the return code to its callers, which are: - read_guest_real() - see below - write_guest_real() - see below There are the following users of read_guest_real(): - ar_translation() in gaccess.c which already returns PGM_* - setup_apcb10(), setup_apcb00(), setup_apcb11() in vsie.c which always return -EFAULT on read_guest_read() nonzero return - no change - shadow_crycb(), handle_stfle() always present this as validity, this could be handled better but doesn't change current behaviour - no change There are the following users of write_guest_real(): - kvm_s390_store_status_unloaded() always returns -EFAULT on write_guest_real() failure. Fixes: 2293897805c2 ("KVM: s390: add architecture compliant guest access functions") Cc: stable@vger.kernel.org Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20240917151904.74314-2-nrb@linux.ibm.com Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>