linux-stable.git/arch/arm, branch linux-6.11.y

ARM: dts: omap36xx: declare 1GHz OPP as turbo again

2024-12-05T12:54:14+00:00

commit 96a64e9730c2c76cfa5c510583a0fbf40d62886b upstream.

Operating stable without reduced chip life at 1Ghz needs several
technologies working: The technologies involve
- SmartReflex
- DVFS

As this cannot directly specified in the OPP table as dependecies in the
devicetree yet, use the turbo flag again to mark this OPP as something
special to have some kind of opt-in.

So revert commit
5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants")

Practical reasoning:
At least the GTA04A5 (DM3730) has become unstable with that OPP enabled.
Furthermore nothing enforces the availability of said technologies,
even in the kernel configuration, so allow users to rather opt-in.

Cc: Stable@vger.kernel.org
Fixes: 5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants")
Signed-off-by: Andreas Kemnade 
Link: https://lore.kernel.org/r/20241018214727.275162-1-andreas@kemnade.info
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify

2024-12-05T12:53:03+00:00

[ Upstream commit b2473a359763e27567993e7d8f37de82f57a0829 ]

 __pa() is only intended to be used for linear map addresses and using
it for initial_boot_params which is in fixmap for arm64 will give an
incorrect value. Hence save the physical address when it is known at
boot time when calling early_init_dt_scan for arm64 and use it at kexec
time instead of converting the virtual address using __pa().

Note that arm64 doesn't need the FDT region reserved in the DT as the
kernel explicitly reserves the passed in FDT. Therefore, only a debug
warning is fixed with this change.

Reported-by: Breno Leitao 
Suggested-by: Mark Rutland 
Signed-off-by: Usama Arif 
Fixes: ac10be5cdbfa ("arm64: Use common of_kexec_alloc_and_setup_fdt()")
Link: https://lore.kernel.org/r/20241023171426.452688-1-usamaarif642@gmail.com
Signed-off-by: Rob Herring (Arm) 
Signed-off-by: Sasha Levin

ARM: dts: cubieboard4: Fix DCDC5 regulator constraints

2024-12-05T12:53:02+00:00

[ Upstream commit dd36ad71ad65968f97630808bc8d605c929b128e ]

The DCDC5 voltage rail in the X-Powers AXP809 PMIC has a resolution of
50mV, so the currently enforced limits of 1.475 and 1.525 volts cannot
be set, when the existing regulator value is beyond this range.

This will lead to the whole regulator driver to give up and fail
probing, which in turn will hang the system, as essential devices depend
on the PMIC.
In this case a bug in U-Boot set the voltage to 1.75V (meant for DCDC4),
and the AXP driver's attempt to correct this lead to this error:
==================
[    4.447653] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded
[    4.450066] vcc-dram: Bringing 1750000uV into 1575000-1575000uV
[    4.460272] vcc-dram: failed to apply 1575000-1575000uV constraint: -EINVAL
[    4.474788] axp20x-regulator axp20x-regulator.0: Failed to register dcdc5
[    4.482276] axp20x-regulator axp20x-regulator.0: probe with driver axp20x-regulator failed with error -22
==================

Set the limits to values that can be programmed, so any correction will
be successful.

Signed-off-by: Andre Przywara 
Fixes: 1e1dea72651b ("ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and regulators")
Link: https://patch.msgid.link/20241007222916.19013-1-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Sasha Levin

ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode

2024-12-05T12:52:58+00:00

[ Upstream commit 2f9d013a0c6f1b9109ada5acb28ee26eefc77c03 ]

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 =  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 
Signed-off-by: Andrei Simion 
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 
Signed-off-by: Sasha Levin

ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash

2024-12-05T12:52:56+00:00

[ Upstream commit 48e17816c3effa3545e21cd4f7d5a00c55c17a18 ]

Second partition was too large, looks like two digits got mixed up.
Fixes:

mtd: partition "user1" extends beyond the end of device "18000000.flash" -- size truncated to 0x4000000

Fixes: 30e0a8cf886c ("ARM: dts: renesas: genmai: Add FLASH nodes")
Signed-off-by: Wolfram Sang 
Reviewed-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/20240914182948.94031-2-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Sasha Levin

ARM: 9434/1: cfi: Fix compilation corner case

2024-12-05T12:52:42+00:00

[ Upstream commit 4aea16b7cfb76bd3361858ceee6893ef5c9b5570 ]

When enabling expert mode CONFIG_EXPERT and using that power
user mode to disable the branch prediction hardening
!CONFIG_HARDEN_BRANCH_PREDICTOR, the assembly linker
in CLANG notices that some assembly in proc-v7.S does
not have corresponding C call sites, i.e. the prototypes
in proc-v7-bugs.c are enclosed in ifdef
CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly:

SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm)
SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm)

Results in:

ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm
>>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94)
>>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a

ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm
>>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105)
>>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a

Fix this by adding an additional requirement that
CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile
these assembly calls.

Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/

Reported-by: kernel test robot 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

ARM: 9420/1: smp: Fix SMP for xip kernels

2024-12-05T12:52:42+00:00

[ Upstream commit 9e9b0cf9319b4db143014477b0bc4b39894248f1 ]

Fix the physical address calculation of the following to get smp working
on xip kernels.
- secondary_data needed for secondary cpu bootup.
- secondary_startup address passed through psci.
- identity mapped code region needed for enabling mmu for secondary cpus.

Signed-off-by: Harith George 
Reviewed-by: Linus Walleij 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32

2024-11-22T14:39:51+00:00

commit 31daa34315d45d3fe77f2158d889d523d78852ea upstream.

Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using Open Firmware.
On these machines, the kernel refuses to boot from non-zero
PHYSICAL_START, which occurs when CRASH_DUMP is on.

Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should
default to off for them.  Users booting via some other mechanism can still
turn it on explicitly.

Does not change the default on any other architectures for the
time being.

Link: https://lkml.kernel.org/r/20240917163720.1644584-1-dave@vasilevsky.ca
Fixes: 75bc255a7444 ("crash: clean up kdump related config items")
Signed-off-by: Dave Vasilevsky 
Reported-by: Reimar Döffinger 
Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html
Acked-by: Michael Ellerman 	[powerpc]
Acked-by: Baoquan He 
Cc: "Eric W. Biederman" 
Cc: John Paul Adrian Glaubitz 
Cc: Reimar Döffinger 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

ARM: fix cacheflush with PAN

2024-11-22T14:39:50+00:00

[ Upstream commit ca29cfcc4a21083d671522ad384532e28a43f033 ]

It seems that the cacheflush syscall got broken when PAN for LPAE was
implemented. User access was not enabled around the cache maintenance
instructions, causing them to fault.

Fixes: 7af5b901e847 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement")
Reported-by: Michał Pecio 
Tested-by: Michał Pecio 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels

2024-11-22T14:39:50+00:00

[ Upstream commit ed6cbe6e5563452f305e89c15846820f2874e431 ]

The patchset introducing kernel_sec_start/end variables to separate the
kernel/lowmem memory mappings, broke the mapping of the kernel memory
for xipkernels.

kernel_sec_start/end variables are in RO area before the MMU is switched
on for xipkernels.
So these cannot be set early in boot in head.S. Fix this by setting these
after MMU is switched on.
xipkernels need two different mappings for kernel text (starting at
CONFIG_XIP_PHYS_ADDR) and data (starting at CONFIG_PHYS_OFFSET).
Also, move the kernel code mapping from devicemaps_init() to map_kernel().

Fixes: a91da5457085 ("ARM: 9089/1: Define kernel physical section start and end")
Signed-off-by: Harith George 
Reviewed-by: Linus Walleij 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin