summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-12-06Merge tag 'arm-soc/for-6.7/devicetree-fixes' of ↵Arnd Bergmann1-3/+1
https://github.com/Broadcom/stblinux into arm/fixes This pull request contains Broadcom ARM-based SoCs Device Tree fixes for 6.7, please pull the following: - Stefan corrects the disabling of the activity LED for the Raspberry Pi 400 * tag 'arm-soc/for-6.7/devicetree-fixes' of https://github.com/Broadcom/stblinux: ARM: dts: bcm2711-rpi-400: Fix delete-node of led_act Link: https://lore.kernel.org/r/20231205225021.653045-1-florian.fainelli@broadcom.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-12-06Merge tag 'riscv-dt-fixes-for-v6.7-rc4' of ↵Arnd Bergmann7-36/+1
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes RISC-V Devicetree fixes for v6.7-rc4 Two fixes, both rather minor. The first fixes some dtbs_check warnings introduced after an update to the bindings, that returns the architecture to being clean of dtbs_check issues. The second relocates a soc-specific property to the appropriate location in $soc.dtsi, and hopefully avoids the same mistake being copy-pasted into more devicetrees. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-dt-fixes-for-v6.7-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: dts: microchip: move timebase-frequency to mpfs.dtsi riscv: dts: sophgo: remove address-cells from intc node Link: https://lore.kernel.org/r/20231130-maternity-majestic-dd29f0170050@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-12-06Merge tag 'mtk-dts64-fixes-for-6.7' of ↵Arnd Bergmann12-205/+241
git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into arm/fixes MediaTek ARM64 DeviceTree fixes for v6.7 Fixes for various MediaTek SoCs, including MT7986: - eMMC HS400 mode failures - Cooling trips for emergency system shutdown - BPI-R3 machine SFP power limit and active cooling MT8173: - EVB device tree unit_address_vs_reg warning MT8183: - unit_address_vs_reg and simple_bus_reg warnings - Kukui device tree nodes naming consistency and adhering to bindings - Jacuzzi device tree unnecessary cells removed as those were producing avoid_unnecessary_addr_size MT8186: - Power domains faults due to incorrect clocks - GPU speed bin nvmem cell name was wrong, producing issues with interpreting the speedbin with GPU OPPs MT8195: - Local Arbiter (and whole system) ability to suspend - Cherry device tree interrupts_property warning ...and another unit_address_vs_reg warning on MT7622. * tag 'mtk-dts64-fixes-for-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux: arm64: dts: mediatek: cherry: Fix interrupt cells for MT6360 on I2C7 arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi unnecessary cells properties arm64: dts: mediatek: mt7622: fix memory node warning check arm64: dts: mediatek: mt8186: fix clock names for power domains arm64: dts: mediatek: mt8186: Change gpu speedbin nvmem cell name arm64: dts: mt7986: change cooling trips arm64: dts: mt7986: define 3W max power to both SFP on BPI-R3 arm64: dts: mt7986: fix emmc hs400 mode without uboot initialization arm64: dts: mt8183: kukui: Fix underscores in node names arm64: dts: mediatek: mt8183: Move thermal-zones to the root node arm64: dts: mediatek: mt8173-evb: Fix regulator-fixed node names arm64: dts: mediatek: mt8183-evb: Fix unit_address_vs_reg warning on ntc arm64: dts: mediatek: mt8183: Fix unit address for scp reserved memory arm64: dts: mediatek: mt8195: Fix PM suspend/resume with venc clocks Link: https://lore.kernel.org/r/20231129113905.134732-1-angelogioacchino.delregno@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-12-06riscv: errata: andes: Probe for IOCP only once in boot stageLad Prabhakar1-7/+13
We need to probe for IOCP only once during boot stage, as we were probing for IOCP for all the stages this caused the below issue during module-init stage, [9.019104] Unable to handle kernel paging request at virtual address ffffffff8100d3a0 [9.027153] Oops [#1] [9.029421] Modules linked in: rcar_canfd renesas_usbhs i2c_riic can_dev spi_rspi i2c_core [9.037686] CPU: 0 PID: 90 Comm: udevd Not tainted 6.7.0-rc1+ #57 [9.043756] Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT) [9.050339] epc : riscv_noncoherent_supported+0x10/0x3e [9.055558]  ra : andes_errata_patch_func+0x4a/0x52 [9.060418] epc : ffffffff8000d8c2 ra : ffffffff8000d95c sp : ffffffc8003abb00 [9.067607]  gp : ffffffff814e25a0 tp : ffffffd80361e540 t0 : 0000000000000000 [9.074795]  t1 : 000000000900031e t2 : 0000000000000001 s0 : ffffffc8003abb20 [9.081984]  s1 : ffffffff015b57c7 a0 : 0000000000000000 a1 : 0000000000000001 [9.089172]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : ffffffff8100d8be [9.096360]  a5 : 0000000000000001 a6 : 0000000000000001 a7 : 000000000900031e [9.103548]  s2 : ffffffff015b57d7 s3 : 0000000000000001 s4 : 000000000000031e [9.110736]  s5 : 8000000000008a45 s6 : 0000000000000500 s7 : 000000000000003f [9.117924]  s8 : ffffffc8003abd48 s9 : ffffffff015b1140 s10: ffffffff8151a1b0 [9.125113]  s11: ffffffff015b1000 t3 : 0000000000000001 t4 : fefefefefefefeff [9.132301]  t5 : ffffffff015b57c7 t6 : ffffffd8b63a6000 [9.137587] status: 0000000200000120 badaddr: ffffffff8100d3a0 cause: 000000000000000f [9.145468] [<ffffffff8000d8c2>] riscv_noncoherent_supported+0x10/0x3e [9.151972] [<ffffffff800027e8>] _apply_alternatives+0x84/0x86 [9.157784] [<ffffffff800029be>] apply_module_alternatives+0x10/0x1a [9.164113] [<ffffffff80008fcc>] module_finalize+0x5e/0x7a [9.169583] [<ffffffff80085cd6>] load_module+0xfd8/0x179c [9.174965] [<ffffffff80086630>] init_module_from_file+0x76/0xaa [9.180948] [<ffffffff800867f6>] __riscv_sys_finit_module+0x176/0x2a8 [9.187365] [<ffffffff80889862>] do_trap_ecall_u+0xbe/0x130 [9.192922] [<ffffffff808920bc>] ret_from_exception+0x0/0x64 [9.198573] Code: 0009 b7e9 6797 014d a783 85a7 c799 4785 0717 0100 (0123) aef7 [9.205994] ---[ end trace 0000000000000000 ]--- This is because we called riscv_noncoherent_supported() for all the stages during IOCP probe. riscv_noncoherent_supported() function sets noncoherent_supported variable to true which has an annotation set to "__ro_after_init" due to which we were seeing the above splat. Fix this by probing for IOCP only once in boot stage by having a boolean variable "done" which will be set to true upon IOCP probe in errata_probe_iocp() and we bail out early if "done" is set to true. While at it make return type of errata_probe_iocp() to void as we were not checking the return value in andes_errata_patch_func(). Fixes: e021ae7f5145 ("riscv: errata: Add Andes alternative ports") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com> Link: https://lore.kernel.org/r/20231130212647.108746-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-06riscv: Fix SMP when shadow call stacks are enabledSamuel Holland1-1/+1
This fixes two bugs in SCS initialization for secondary CPUs. First, the SCS was not initialized at all in the spinwait boot path. Second, the code for the SBI HSM path attempted to initialize the SCS before enabling the MMU. However, that involves dereferencing the thread pointer, which requires the MMU to be enabled. Fix both issues by setting up the SCS in the common secondary entry path, after enabling the MMU. Fixes: d1584d791a29 ("riscv: Implement Shadow Call Stack") Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20231121211958.3158576-1-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-06riscv: fix misaligned access handling of C.SWSP and C.SDSPClément Léger1-4/+2
This is a backport of a fix that was done in OpenSBI: ec0559eb315b ("lib: sbi_misaligned_ldst: Fix handling of C.SWSP and C.SDSP"). Unlike C.LWSP/C.LDSP, these encodings can be used with the zero register, so checking that the rs2 field is non-zero is unnecessary. Additionally, the previous check was incorrect since it was checking the immediate field of the instruction instead of the rs2 field. Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Signed-off-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20231103090223.702340-1-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-06RISC-V: hwprobe: Always use u64 for extension bitsAndrew Jones1-1/+1
Extensions are getting added quickly and their hwprobe bits will soon exceed 31 (which pair values accommodate, since they're of type u64). However, in one tree, where a bunch of extensions got merged prior to zicboz, zicboz already got pushed to bit 32. Pushing it exposed a 32-bit compilation bug, since unsigned long was used instead of u64. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310311801.hxduISrr-lkp@intel.com/ Fixes: 9c7646d5ffd2 ("RISC-V: hwprobe: Expose Zicboz extension and its block size") Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20231101141908.192198-2-ajones@ventanamicro.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-06Support rv32 ULEB128 testCharlie Jenkins1-4/+4
Use opcodes available to both rv32 and rv64 in uleb128 module linking test. Fixes: af71bc194916 ("riscv: Add tests for riscv module loading") Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/lkml/1d7c71ee-5742-4df4-b8ef-a2aea0a624eb@infradead.org/ Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://lore.kernel.org/r/20231122-module_fixup-v2-1-dfb9565e9ea5@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-06arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588Sam Edwards1-1/+1
JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees. Fixes: d85f8a5c798d5 ("arm64: dts: rockchip: Add rk3588 pinctrl data") Signed-off-by: Sam Edwards <CFSworks@gmail.com> Link: https://lore.kernel.org/r/20231205202900.4617-2-CFSworks@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-12-06ARM: dts: imx28-xea: Pass the 'model' propertyFabio Estevam1-0/+1
Per root-node.yaml, 'model' is a required property. Pass it to fix the following dt-schema warning: imx28-xea.dtb: /: 'model' is a required property from schema $id: http://devicetree.org/schemas/root-node.yaml# Signed-off-by: Fabio Estevam <festevam@denx.de> Fixes: 445ae16ac1c5 ("ARM: dts: imx28: Add DTS description of imx28 based XEA board") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06ARM: dts: imx7: Declare timers compatible with fsl,imx6dl-gptPhilipp Zabel1-4/+4
The timer nodes declare compatibility with "fsl,imx6sx-gpt", which itself is compatible with "fsl,imx6dl-gpt". Switch the fallback compatible from "fsl,imx6sx-gpt" to "fsl,imx6dl-gpt". Fixes: 949673450291 ("ARM: dts: add imx7d soc dtsi file") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: imx8-apalis: set wifi regulator to always-onStefan Eichenberger1-4/+1
Make sure that the wifi regulator is always on. The wifi driver itself puts the wifi module into suspend mode. If we cut the power the driver will crash when resuming from suspend. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Fixes: ad0de4ceb706 ("arm64: dts: freescale: add initial apalis imx8 aka quadmax module support") Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06ARM: imx: Check return value of devm_kasprintf in imx_mmdc_perf_initKunwu Chan1-1/+6
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Release the id allocated in 'mmdc_pmu_init' when 'devm_kasprintf' return NULL Suggested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Fixes: e76bdfd7403a ("ARM: imx: Added perf functionality to mmdc driver") Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: imx8ulp: update gpio node name to align with register addressHaibo Chen1-3/+3
Change the gpio node name to align with register address. Fixes: ac7bcf48ddba ("arm64: dts: imx8ulp: update gpio node") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: imx93: update gpio node name to align with register addressHaibo Chen1-4/+4
Change the gpio node name to align with register address Fixes: c1d0782b5fc3 ("arm64: dts: imx93: update gpio node") Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: imx93: correct mediamix powerPeng Fan1-1/+1
"nic_media" clock should be enabled when power on/off mediamix, otherwise power on/off will fail. Because "media_axi_root" clock is the parent of "nic_media" clock, so replace "media_axi_clock" clock with "nic_media" clock in mediamix node. Link: https://github.com/nxp-imx/linux-imx/commit/ce18e6d0071ae9df5486af8613708ebe920484be Fixes: f2d03ba997cb ("arm64: dts: imx93: reorder device nodes") Fixes: e85d3458a804 ("arm64: dts: imx93: add src node") Reviewed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: imx8qm: Add imx8qm's own pm to avoid panic during startupXiaolei Wang1-0/+11
Add imx8qm's own pm, otherwise the following panic will occur during the startup process: Kernel panic - not syncing: Asynchronous SError Interrupt Hardware name: Freescale i.MX8QM MEK (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x98/0xf0 show_stack+0x18/0x24 dump_stack_lvl+0x60/0xac dump_stack+0x18/0x24 panic+0x340/0x3a0 nmi_panic+0x8c/0x90 arm64_serror_panic+0x6c/0x78 do_serror+0x3c/0x78 el1h_64_error_handler+0x38/0x50 el1h_64_error+0x64/0x68 fsl_edma_chan_mux+0x98/0xdc fsl_edma_probe+0x278/0x898 platform_probe+0x68/0xd8 really_probe+0x110/0x27c __driver_probe_device+0x78/0x12c driver_probe_device+0x3c/0x118 __device_attach_driver+0xb8/0xf8 bus_for_each_drv+0x84/0xe4 __device_attach+0xfc/0x18c device_initial_probe+0x14/0x20 Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]") Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: freescale: imx8-ss-dma: Fix #pwm-cellsAlexander Stein1-1/+1
i.MX8QXP supports inverted PWM output, thus #pwm-cells needs to be set to 3. Fixes: f1d6a6b991ef9 ("arm64: dts: imx8qxp: add adma_pwm in adma") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-06arm64: dts: freescale: imx8-ss-lsio: Fix #pwm-cellsAlexander Stein1-4/+4
i.MX8QM/QXP supports inverted PWM output, thus #pwm-cells needs to be set to 3. Fixes: 23fa99b205ea ("arm64: dts: freescale: imx8-ss-lsio: add support for lsio_pwm0-3") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-05MIPS: kernel: Clear FPU states when setting up kernel threadsThomas Bogendoerfer1-12/+13
io_uring sets up the io worker kernel thread via a syscall out of an user space prrocess. This process might have used FPU and since copy_thread() didn't clear FPU states for kernel threads a BUG() is triggered for using FPU inside kernel. Move code around to always clear FPU state for user and kernel threads. Cc: stable@vger.kernel.org Reported-by: Aurelien Jarno <aurel32@debian.org> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055021 Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-12-05MIPS: Loongson64: Handle more memory types passed from firmwareJiaxun Yang2-17/+31
There are many types of revsered memory passed from firmware that should be reserved in memblock, and UMA memory passed from firmware that should be added to system memory for system to use. Also for memblock there is no need to align those space into page, which actually cause problems. Handle them properly to prevent memory corruption on some systems. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-12-05MIPS: Loongson64: Enable DMA noncoherent supportJiaxun Yang3-2/+13
There are some Loongson64 systems come with broken coherent DMA support, firmware will set a bit in boot_param and pass nocoherentio in cmdline. However nonconherent support was missed out when spin off Loongson-2EF form Loongson64, and that boot_param change never made itself into upstream. Support DMA noncoherent properly to get those systems working. Cc: stable@vger.kernel.org Fixes: 71e2f4dd5a65 ("MIPS: Fork loongson2ef from loongson64") Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-12-05MIPS: Loongson64: Reserve vgabios memory on bootJiaxun Yang1-0/+5
vgabios is passed from firmware to kernel on Loongson64 systems. Sane firmware will keep this pointer in reserved memory space passed from the firmware but insane firmware keeps it in low memory before kernel entry that is not reserved. Previously kernel won't try to allocate memory from low memory before kernel entry on boot, but after converting to memblock it will do that. Fix by resversing those memory on early boot. Cc: stable@vger.kernel.org Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-12-05mips/smp: Call rcutree_report_cpu_starting() earlierStefan Wiehler1-2/+2
rcutree_report_cpu_starting() must be called before clockevents_register_device() to avoid the following lockdep splat triggered by calling list_add() when CONFIG_PROVE_RCU_LIST=y: WARNING: suspicious RCU usage ... ----------------------------- kernel/locking/lockdep.c:3680 RCU-list traversed in non-reader section!! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/1/0. ... Call Trace: [<ffffffff8012a434>] show_stack+0x64/0x158 [<ffffffff80a93d98>] dump_stack_lvl+0x90/0xc4 [<ffffffff801c9e9c>] __lock_acquire+0x1404/0x2940 [<ffffffff801cbf3c>] lock_acquire+0x14c/0x448 [<ffffffff80aa4260>] _raw_spin_lock_irqsave+0x50/0x88 [<ffffffff8021e0c8>] clockevents_register_device+0x60/0x1e8 [<ffffffff80130ff0>] r4k_clockevent_init+0x220/0x3a0 [<ffffffff801339d0>] start_secondary+0x50/0x3b8 raw_smp_processor_id() is required in order to avoid calling into lockdep before RCU has declared the CPU to be watched for readers. See also commit 29368e093921 ("x86/smpboot: Move rcu_cpu_starting() earlier"), commit de5d9dae150c ("s390/smp: move rcu_cpu_starting() earlier") and commit 99f070b62322 ("powerpc/smp: Call rcu_cpu_starting() earlier"). Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-12-05ARM: dts: imx6ul-pico: Describe the Ethernet PHY clockFabio Estevam1-0/+2
Since commit c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup")thet Ethernet PHY is no longer configured via code in board file. This caused Ethernet to stop working. Fix this problem by describing the clocks and clock-names to the Ethernet PHY node so that the KSZ8081 chip can be clocked correctly. Fixes: c7e73b5051d6 ("ARM: imx: mach-imx6ul: remove 14x14 EVK specific PHY fixup") Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-05arm64: dts: imx8mp: imx8mq: Add parkmode-disable-ss-quirk on DWC3Nathan Rossi2-0/+4
The i.MX8MP and i.MX8MQ devices both use the same DWC3 controller and are both affected by a known issue with the controller due to specific behaviour when park mode is enabled in SuperSpeed host mode operation. Under heavy USB traffic from multiple endpoints the controller will sometimes incorrectly process transactions such that some transactions are lost, or the controller may hang when processing transactions. When the controller hangs it does not recover. This issue is documented partially within the linux-imx vendor kernel which references a Synopsys STAR number 9001415732 in commits [1] and additional details in [2]. Those commits provide some additional controller internal implementation specifics around the incorrect behaviour of the SuperSpeed host controller operation when park mode is enabled. The summary of this issue is that the host controller can incorrectly enter/exit park mode such that part of the controller is in a state which behaves as if in park mode even though it is not. In this state the controller incorrectly calculates the number of TRBs available which results in incorrect access of the internal caches causing the overwrite of pending requests in the cache which should have been processed but are ignored. This can cause the controller to drop the requests or hang waiting for the pending state of the dropped requests. The workaround for this issue is to disable park mode for SuperSpeed operation of the controller through the GUCTL1[17] bit. This is already available as a quirk for the DWC3 controller and can be enabled via the 'snps,parkmode-disable-ss-quirk' device tree property. It is possible to replicate this failure on an i.MX8MP EVK with a USB Hub connecting 4 SuperSpeed USB flash drives. Performing continuous small read operations (dd if=/dev/sd... of=/dev/null bs=16) on the block devices will result in device errors initially and will eventually result in the controller hanging. [13240.896936] xhci-hcd xhci-hcd.0.auto: WARN Event TRB for slot 4 ep 2 with no TDs queued? [13240.990708] usb 2-1.3: reset SuperSpeed USB device number 5 using xhci-hcd [13241.015582] sd 2:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [13241.025198] sd 2:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00 [13241.032949] I/O error, dev sdc, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 25 prio class 2 [13272.150710] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd [13272.175469] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=DRIVER_OK cmd_age=31s [13272.185365] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 03 e0 00 01 00 00 [13272.193385] I/O error, dev sdb, sector 992 op 0x0:(READ) flags 0x80700 phys_seg 18 prio class 2 [13434.846556] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command [13434.854592] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead [13434.862553] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up [1] https://github.com/nxp-imx/linux-imx/commit/97a5349d936b08cf301730b59e4e8855283f815c [2] https://github.com/nxp-imx/linux-imx/commit/b4b5cbc5a12d7c3b920d1d7cba0ada3379e4e42b Fixes: fb8587a2c165 ("arm64: dtsi: imx8mp: add usb nodes") Fixes: ad37549cb5dc ("arm64: dts: imx8mq: add USB nodes") Signed-off-by: Nathan Rossi <nathan.rossi@digi.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2023-12-05powerpc/ftrace: Fix stack teardown in ftrace_no_traceNaveen N Rao1-2/+2
Commit 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix stack unwind") added use of a new stack frame on ftrace entry to fix stack unwind. However, the commit missed updating the offset used while tearing down the ftrace stack when ftrace is disabled. Fix the same. In addition, the commit missed saving the correct stack pointer in pt_regs. Update the same. Fixes: 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix stack unwind") Cc: stable@vger.kernel.org # v6.5+ Signed-off-by: Naveen N Rao <naveen@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231130065947.2188860-1-naveen@kernel.org
2023-12-04arm64: dts: rockchip: Fix PCI node addresses on rk3399-gruRob Herring3-4/+4
The rk3399-gru PCI node addresses are wrong. In rk3399-gru-scarlet, the bus number in the address should be 0. This is because bus number assignment is dynamic and not known up front. For FDT, the bus number is simply ignored. In rk3399-gru-chromebook, the addresses are simply invalid. The first "reg" entry must be the configuration space for the device. The entry should be all 0s except for device/slot and function numbers. The existing 64-bit memory space (0x83000000) entries are not valid because they must have the BAR address in the lower byte of the first cell. Warnings for these are enabled by adding the missing 'device_type = "pci"' for the root port node. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-12-04arm64: dts: rockchip: drop interrupt-names property from rk3588s dfiHeiko Stuebner1-1/+0
The dfi binding does not specify interrupt names, with the interrupts just specifying channels 0-x. So drop the unspecified property. Fixes: 5a6976b1040a ("arm64: dts: rockchip: Add DFI to rk3588s") Reported-by: Jagan Teki <jagan@edgeble.ai> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Link: https://lore.kernel.org/r/20231201134859.322491-1-heiko@sntech.de
2023-12-04riscv: Correct type casting in module loadingCharlie Jenkins1-2/+2
Use __le16 with le16_to_cpu. Fixes: 8fd6c5142395 ("riscv: Add remaining module relocations") Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Tested-by: Samuel Holland <samuel.holland@sifive.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20231127-module_linking_freeing-v4-2-a2ca1d7027d0@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-04riscv: Safely remove entries from relocation listCharlie Jenkins1-28/+82
Use the safe versions of list and hlist iteration to safely remove entries from the module relocation lists. To allow mutliple threads to load modules concurrently, move relocation list pointers onto the stack rather than using global variables. Fixes: 8fd6c5142395 ("riscv: Add remaining module relocations") Reported-by: Ron Economos <re@w6rz.net> Closes: https://lore.kernel.org/linux-riscv/444de86a-7e7c-4de7-5d1d-c1c40eefa4ba@w6rz.net Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20231127-module_linking_freeing-v4-1-a2ca1d7027d0@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-03Merge tag 'powerpc-6.7-3' of ↵Linus Torvalds3-3/+18
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: - Fix corruption of f0/vs0 during FP/Vector save, seen as userspace crashes when using io-uring workers (in particular with MariaDB) - Fix KVM_RUN potentially clobbering all host userspace FP/Vector registers Thanks to Timothy Pearson, Jens Axboe, and Nicholas Piggin. * tag 'powerpc-6.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers powerpc: Don't clobber f0/vs0 during fp|altivec register save
2023-12-03Merge tag 'for-linus-6.7a-rc4-tag' of ↵Linus Torvalds2-2/+6
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - A fix for the Xen event driver setting the correct return value when experiencing an allocation failure - A fix for allocating space for a struct in the percpu area to not cross page boundaries (this one is for x86, a similar one for Arm was already in the pull request for rc3) * tag 'for-linus-6.7a-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/events: fix error code in xen_bind_pirq_msi_to_irq() x86/xen: fix percpu vcpu_info allocation
2023-12-02arm64: dts: rockchip: Fix Turing RK1 interrupt pinctrlsSam Edwards1-2/+2
The pinctrls for the hym8563 interrupt line and fan-tach input were both mistakenly defined as `pcfg_pull_none`. As these are active-low signals (level-triggered, in the hym8563 case) which may not be driven at times, these should really be pull-up. The lack of any bias results in spurious interrupts. Fix this by modifying the `rockchip,pins` properties as necessary to enable the pull-up resistors. Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") Signed-off-by: Sam Edwards <CFSworks@gmail.com> Link: https://lore.kernel.org/r/20231202071212.1606800-1-CFSworks@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-12-02x86/CPU/AMD: Check vendor in the AMD microcode callbackBorislav Petkov (AMD)1-0/+3
Commit in Fixes added an AMD-specific microcode callback. However, it didn't check the CPU vendor the kernel runs on explicitly. The only reason the Zenbleed check in it didn't run on other x86 vendors hardware was pure coincidental luck: if (!cpu_has_amd_erratum(c, amd_zenbleed)) return; gives true on other vendors because they don't have those families and models. However, with the removal of the cpu_has_amd_erratum() in 05f5f73936fa ("x86/CPU/AMD: Drop now unused CPU erratum checking function") that coincidental condition is gone, leading to the zenbleed check getting executed on other vendors too. Add the explicit vendor check for the whole callback as it should've been done in the first place. Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix") Cc: <stable@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231201184226.16749-1-bp@alien8.de
2023-12-02Merge tag 'arm64-fixes' of ↵Linus Torvalds1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fix from Catalin Marinas: "Fix a regression where the arm64 KPTI ends up enabled even on systems that don't need it" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Avoid enabling KPTI unnecessarily
2023-12-01KVM: x86: Remove 'return void' expression for 'void function'Like Xu1-2/+2
The requested info will be stored in 'guest_xsave->region' referenced by the incoming pointer "struct kvm_xsave *guest_xsave", thus there is no need to explicitly use return void expression for a void function "static void kvm_vcpu_ioctl_x86_get_xsave(...)". The issue is caught with [-Wpedantic]. Fixes: 2d287ec65e79 ("x86/fpu: Allow caller to constrain xfeatures when copying to uabi buffer") Signed-off-by: Like Xu <likexu@tencent.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20231007064019.17472-1-likexu@tencent.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-12-01KVM: Set file_operations.owner appropriately for all such structuresSean Christopherson1-0/+1
Set .owner for all KVM-owned filed types so that the KVM module is pinned until any files with callbacks back into KVM are completely freed. Using "struct kvm" as a proxy for the module, i.e. keeping KVM-the-module alive while there are active VMs, doesn't provide full protection. Userspace can invoke delete_module() the instant the last reference to KVM is put. If KVM itself puts the last reference, e.g. via kvm_destroy_vm(), then it's possible for KVM to be preempted and deleted/unloaded before KVM fully exits, e.g. when the task running kvm_destroy_vm() is scheduled back in, it will jump to a code page that is no longer mapped. Note, file types that can call into sub-module code, e.g. kvm-intel.ko or kvm-amd.ko on x86, must use the module pointer passed to kvm_init(), not THIS_MODULE (which points at kvm.ko). KVM assumes that if /dev/kvm is reachable, e.g. VMs are active, then the vendor module is loaded. To reduce the probability of forgetting to set .owner entirely, use THIS_MODULE for stats files where KVM does not call back into vendor code. This reverts commit 70375c2d8fa3fb9b0b59207a9c5df1e2e1205c10, and fixes several other file types that have been buggy since their introduction. Fixes: 70375c2d8fa3 ("Revert "KVM: set owner of cpu and vm file operations"") Fixes: 3bcd0662d66f ("KVM: X86: Introduce mmu_rmaps_stat per-vm debugfs file") Reported-by: Al Viro <viro@zeniv.linux.org.uk> Link: https://lore.kernel.org/all/20231010003746.GN800259@ZenIV Link: https://lore.kernel.org/r/20231018204624.1905300-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-11-30arm64: Avoid enabling KPTI unnecessarilyArd Biesheuvel1-0/+4
Commit 42c5a3b04bf6 refactored the KPTI init code in a way that results in the use of non-global kernel mappings even on systems that have no need for it, and even when KPTI has been disabled explicitly via the command line. Ensure that this only happens when we have decided (based on the detected system-wide CPU features) that KPTI should be enabled. Fixes: 42c5a3b04bf6 ("arm64: Split kpti_install_ng_mappings()") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20231127120049.2258650-6-ardb@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-11-30x86/sev: Fix kernel crash due to late update to read-only ghcb_versionAshwin Dayanand Kamat1-4/+7
A write-access violation page fault kernel crash was observed while running cpuhotplug LTP testcases on SEV-ES enabled systems. The crash was observed during hotplug, after the CPU was offlined and the process was migrated to different CPU. setup_ghcb() is called again which tries to update ghcb_version in sev_es_negotiate_protocol(). Ideally this is a read_only variable which is initialised during booting. Trying to write it results in a pagefault: BUG: unable to handle page fault for address: ffffffffba556e70 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation [ ...] Call Trace: <TASK> ? __die_body.cold+0x1a/0x1f ? __die+0x2a/0x35 ? page_fault_oops+0x10c/0x270 ? setup_ghcb+0x71/0x100 ? __x86_return_thunk+0x5/0x6 ? search_exception_tables+0x60/0x70 ? __x86_return_thunk+0x5/0x6 ? fixup_exception+0x27/0x320 ? kernelmode_fixup_or_oops+0xa2/0x120 ? __bad_area_nosemaphore+0x16a/0x1b0 ? kernel_exc_vmm_communication+0x60/0xb0 ? bad_area_nosemaphore+0x16/0x20 ? do_kern_addr_fault+0x7a/0x90 ? exc_page_fault+0xbd/0x160 ? asm_exc_page_fault+0x27/0x30 ? setup_ghcb+0x71/0x100 ? setup_ghcb+0xe/0x100 cpu_init_exception_handling+0x1b9/0x1f0 The fix is to call sev_es_negotiate_protocol() only in the BSP boot phase, and it only needs to be done once in any case. [ mingo: Refined the changelog. ] Fixes: 95d33bfaa3e1 ("x86/sev: Register GHCB memory when SEV-SNP is active") Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Co-developed-by: Bo Gan <bo.gan@broadcom.com> Signed-off-by: Bo Gan <bo.gan@broadcom.com> Signed-off-by: Ashwin Dayanand Kamat <ashwin.kamat@broadcom.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://lore.kernel.org/r/1701254429-18250-1-git-send-email-kashwindayan@vmware.com
2023-11-29KVM: x86: Get CPL directly when checking if loaded vCPU is in kernel modeLike Xu1-1/+4
When querying whether or not a vCPU "is" running in kernel mode, directly get the CPL if the vCPU is the currently loaded vCPU. In scenarios where a guest is profiled via perf-kvm, querying vcpu->arch.preempted_in_kernel from kvm_guest_state() is wrong if vCPU is actively running, i.e. isn't scheduled out due to being preempted and so preempted_in_kernel is stale. This affects perf/core's ability to accurately tag guest RIP with PERF_RECORD_MISC_GUEST_{KERNEL|USER} and record it in the sample. This causes perf/tool to fail to connect the vCPU RIPs to the guest kernel space symbols when parsing these samples due to incorrect PERF_RECORD_MISC flags: Before (perf-report of a cpu-cycles sample): 1.23% :58945 [unknown] [u] 0xffffffff818012e0 After: 1.35% :60703 [kernel.vmlinux] [g] asm_exc_page_fault Note, checking preempted_in_kernel in kvm_arch_vcpu_in_kernel() is awful as nothing in the API's suggests that it's safe to use if and only if the vCPU was preempted. That can be cleaned up in the future, for now just fix the glaring correctness bug. Note #2, checking vcpu->preempted is NOT safe, as getting the CPL on VMX requires VMREAD, i.e. is correct if and only if the vCPU is loaded. If the target vCPU *was* preempted, then it can be scheduled back in after the check on vcpu->preempted in kvm_vcpu_on_spin(), i.e. KVM could end up trying to do VMREAD on a VMCS that isn't loaded on the current pCPU. Signed-off-by: Like Xu <likexu@tencent.com> Fixes: e1bfc24577cc ("KVM: Move x86's perf guest info callbacks to generic KVM") Link: https://lore.kernel.org/r/20231123075818.12521-1-likexu@tencent.com [sean: massage changelong, add Fixes] Signed-off-by: Sean Christopherson <seanjc@google.com>
2023-11-29KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registersNicholas Piggin1-3/+3
Before running a guest, the host process (e.g., QEMU) FP/VEC registers are saved if they were being used, similarly to when the kernel uses FP registers. The guest values are then loaded into regs, and the host process registers will be restored lazily when it uses FP/VEC. KVM HV has a bug here: the host process registers do get saved, but the user MSR bits remain enabled, which indicates the registers are valid for the process. After they are clobbered by running the guest, this valid indication causes the host process to take on the FP/VEC register values of the guest. Fixes: 34e119c96b2b ("KVM: PPC: Book3S HV P9: Reduce mtmsrd instructions required to save host SPRs") Cc: stable@vger.kernel.org # v5.17+ Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20231122025811.2973-1-npiggin@gmail.com
2023-11-29arm64: dts: mediatek: cherry: Fix interrupt cells for MT6360 on I2C7AngeloGioacchino Del Regno1-1/+1
Change interrupt cells to 2 to suppress interrupts_property warning. Cc: stable@vger.kernel.org Fixes: 0de0fe950f1b ("arm64: dts: mediatek: cherry: Enable MT6360 sub-pmic on I2C7") Link: https://lore.kernel.org/r/20231127132026.165027-1-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mediatek: mt8183-kukui-jacuzzi: fix dsi unnecessary cells propertiesEugen Hristev1-0/+2
dtbs_check throws a warning at the dsi node: Warning (avoid_unnecessary_addr_size): /soc/dsi@14014000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Other DTS have a panel child node with a reg, so the parent dtsi must have the address-cells and size-cells, however this specific DT has the panel removed, but not the cells, hence the warning above. If panel is deleted then the cells must also be deleted since they are tied together, as the child node in this DT does not have a reg. Cc: stable@vger.kernel.org Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230814071053.5459-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mediatek: mt7622: fix memory node warning checkEugen Hristev2-2/+2
dtbs_check throws a warning at the memory node: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name fix by adding the address into the node name. Cc: stable@vger.kernel.org Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230814065042.4973-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mediatek: mt8186: fix clock names for power domainsEugen Hristev1-15/+27
Clocks for each power domain are split into big categories: pd clocks and subsys clocks. According to the binding, all clocks which have a dash '-' in their name are treated as subsys clocks, and must be placed at the end of the list. The other clocks which are pd clocks must come first. Fixed the naming and the placing of all clocks in the power domains. For the avoidance of doubt, prefixed all subsys clocks with the 'subsys' prefix. The binding does not enforce strict clock names, the driver uses them in bulk, only making a difference for pd clocks vs subsys clocks. The above problem appears to be trivial, however, it leads to incorrect power up and power down sequence of the power domains, because some clocks will be mistakenly taken for subsys clocks and viceversa. One consequence is the fact that if the DIS power domain goes power down and power back up during the boot process, when it comes back up, there are still transactions left on the bus which makes the display inoperable. Some of the clocks for the DIS power domain were wrongly using '_' instead of '-', which again made these clocks being treated as pd clocks instead of subsys clocks. Cc: stable@vger.kernel.org Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20231005103041.352478-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mediatek: mt8186: Change gpu speedbin nvmem cell nameAngeloGioacchino Del Regno1-1/+1
MT8186's GPU speedbin value must be interpreted, or the value will not be meaningful. Use the correct "gpu-speedbin" nvmem cell name for the GPU speedbin to allow triggering the cell info fixup handler, hence feeding the right speedbin number to the users. Cc: stable@vger.kernel.org Fixes: 263d2fd02afc ("arm64: dts: mediatek: mt8186: Add GPU speed bin NVMEM cells") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20231005151150.355536-1-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mt7986: change cooling tripsFrank Wunderlich2-9/+21
Add Critical and hot trips for emergency system shutdown and limiting system load. Change passive trip to active to make sure fan is activated on the lowest trip. Cc: stable@vger.kernel.org Fixes: 1f5be05132f3 ("arm64: dts: mt7986: add thermal-zones") Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to BPI-R3 dts") Suggested-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231025170832.78727-4-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mt7986: define 3W max power to both SFP on BPI-R3Frank Wunderlich1-0/+2
All SFP power supplies are connected to the system VDD33 which is 3v3/8A. Set 3A per SFP slot to allow SFPs work which need more power than the default 1W. Cc: stable@vger.kernel.org Fixes: 8e01fb15b815 ("arm64: dts: mt7986: add Bananapi R3") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231025170832.78727-3-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2023-11-29arm64: dts: mt7986: fix emmc hs400 mode without uboot initializationEric Woudstra1-0/+4
Eric reports errors on emmc with hs400 mode when booting linux on bpi-r3 without uboot [1]. Booting with uboot does not show this because clocks seem to be initialized by uboot. Fix this by adding assigned-clocks and assigned-clock-parents like it's done in uboot [2]. [1] https://forum.banana-pi.org/t/bpi-r3-kernel-fails-setting-emmc-clock-to-416m-depends-on-u-boot/15170 [2] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/mt7986.dtsi#L287 Cc: stable@vger.kernel.org Fixes: 513b49d19b34 ("arm64: dts: mt7986: add mmc related device nodes") Signed-off-by: Eric Woudstra <ericwouds@gmail.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231025170832.78727-2-linux@fw-web.de Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-19 08:48:38 +0300