aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-07-30arm64: dts: rockchip: enable sata1+2 on Qnap-TS433Heiko Stuebner1-0/+18
The TS433 has 4 bays. The last two are accessed via a pci-connected sata controller, while the first two are accessed via the rk3568's sata controllers. Enable these two now. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-30arm64: dts: rockchip: add stdout path on Qnap-TS433Heiko Stuebner1-0/+4
As most Rockchip boards do, the TS433 also uses uart2 for its serial output. Set the correct chosen entry for it. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-30arm64: dts: rockchip: enable usb ports on Qnap-TS433Heiko Stuebner1-0/+105
Enable usb controllers and phys and add regulator infrastructure for the usb ports on the TS433. Of course there are no schematics available for the device, so the regulator information comes from the vendor-devicetree with unknown accuracy. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-30arm64: dts: rockchip: enable uart0 on Qnap-TS433Heiko Stuebner1-0/+8
Uart0 is connected to an MCU on the board that handles system control like the fan-speed. So far no driver for it is available though. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-30arm64: dts: rockchip: enable second PCIe controller on the Qnap-TS433Heiko Stuebner1-1/+9
The TS433 uses both pcie controllers for sata and the 2nd network interface. Set the needed data-lanes in the pcie3 phy and enable the second pcie controller, as well as remove the bifurcation comment. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-30arm64: dts: rockchip: add PCIe supply regulator to Qnap-TS433Heiko Stuebner1-0/+21
Add the vcc3v3-supply regulator and its link to the pcie controllers. Tested-by: Uwe Kleine-König <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-29ARM: dts: broadcom: bcm21664: Move chosen node into Garnet DTSArtur Weber2-4/+4
The serial console settings in the chosen node are device-specific, not SoC-specific. Move the chosen node out of bcm21664.dtsi and into the only DTS that uses it, bcm21664-garnet.dts. Signed-off-by: Artur Weber <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]>
2024-07-29ARM: dts: broadcom: convert NVMEM content to layout syntaxRafał Miłecki2-8/+16
Use cleaner (and non-deprecated) bindings syntax. See commit bd912c991d2e ("dt-bindings: nvmem: layouts: add fixed-layout") for details. Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]>
2024-07-29arm64: dts: broadcom: Add minimal support for Raspberry Pi 5Andrea della Porta3-0/+348
The BCM2712 SoC family can be found on Raspberry Pi 5. Add minimal SoC and board (Rpi5 specific) dts file to be able to boot from SD card and use console on debug UART. Signed-off-by: Andrea della Porta <[email protected]> Reviewed-by: Stefan Wahren <[email protected]> Link: https://lore.kernel.org/r/874589f6c621036620cca944986e5be7238b4784.1717061147.git.andrea.porta@suse.com Signed-off-by: Florian Fainelli <[email protected]>
2024-07-29bpf, arm64: Fix tailcall hierarchyLeon Hwang1-16/+41
This patch fixes a tailcall issue caused by abusing the tailcall in bpf2bpf feature on arm64 like the way of "bpf, x64: Fix tailcall hierarchy". On arm64, when a tail call happens, it uses tail_call_cnt_ptr to increment tail_call_cnt, too. At the prologue of main prog, it has to initialize tail_call_cnt and prepare tail_call_cnt_ptr. At the prologue of subprog, it pushes x26 register twice, and does not initialize tail_call_cnt. At the epilogue, it pops x26 twice, no matter whether it is main prog or subprog. Fixes: d4609a5d8c70 ("bpf, arm64: Keep tail call count across bpf2bpf calls") Acked-by: Puranjay Mohan <[email protected]> Signed-off-by: Leon Hwang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]>
2024-07-29bpf, x64: Fix tailcall hierarchyLeon Hwang1-28/+79
This patch fixes a tailcall issue caused by abusing the tailcall in bpf2bpf feature. As we know, tail_call_cnt propagates by rax from caller to callee when to call subprog in tailcall context. But, like the following example, MAX_TAIL_CALL_CNT won't work because of missing tail_call_cnt back-propagation from callee to caller. \#include <linux/bpf.h> \#include <bpf/bpf_helpers.h> \#include "bpf_legacy.h" struct { __uint(type, BPF_MAP_TYPE_PROG_ARRAY); __uint(max_entries, 1); __uint(key_size, sizeof(__u32)); __uint(value_size, sizeof(__u32)); } jmp_table SEC(".maps"); int count = 0; static __noinline int subprog_tail1(struct __sk_buff *skb) { bpf_tail_call_static(skb, &jmp_table, 0); return 0; } static __noinline int subprog_tail2(struct __sk_buff *skb) { bpf_tail_call_static(skb, &jmp_table, 0); return 0; } SEC("tc") int entry(struct __sk_buff *skb) { volatile int ret = 1; count++; subprog_tail1(skb); subprog_tail2(skb); return ret; } char __license[] SEC("license") = "GPL"; At run time, the tail_call_cnt in entry() will be propagated to subprog_tail1() and subprog_tail2(). But, when the tail_call_cnt in subprog_tail1() updates when bpf_tail_call_static(), the tail_call_cnt in entry() won't be updated at the same time. As a result, in entry(), when tail_call_cnt in entry() is less than MAX_TAIL_CALL_CNT and subprog_tail1() returns because of MAX_TAIL_CALL_CNT limit, bpf_tail_call_static() in suprog_tail2() is able to run because the tail_call_cnt in subprog_tail2() propagated from entry() is less than MAX_TAIL_CALL_CNT. So, how many tailcalls are there for this case if no error happens? From top-down view, does it look like hierarchy layer and layer? With this view, there will be 2+4+8+...+2^33 = 2^34 - 2 = 17,179,869,182 tailcalls for this case. How about there are N subprog_tail() in entry()? There will be almost N^34 tailcalls. Then, in this patch, it resolves this case on x86_64. In stead of propagating tail_call_cnt from caller to callee, it propagates its pointer, tail_call_cnt_ptr, tcc_ptr for short. However, where does it store tail_call_cnt? It stores tail_call_cnt on the stack of main prog. When tail call happens in subprog, it increments tail_call_cnt by tcc_ptr. Meanwhile, it stores tail_call_cnt_ptr on the stack of main prog, too. And, before jump to tail callee, it has to pop tail_call_cnt and tail_call_cnt_ptr. Then, at the prologue of subprog, it must not make rax as tail_call_cnt_ptr again. It has to reuse tail_call_cnt_ptr from caller. As a result, at run time, it has to recognize rax is tail_call_cnt or tail_call_cnt_ptr at prologue by: 1. rax is tail_call_cnt if rax is <= MAX_TAIL_CALL_CNT. 2. rax is tail_call_cnt_ptr if rax is > MAX_TAIL_CALL_CNT, because a pointer won't be <= MAX_TAIL_CALL_CNT. Here's an example to dump JITed. struct { __uint(type, BPF_MAP_TYPE_PROG_ARRAY); __uint(max_entries, 1); __uint(key_size, sizeof(__u32)); __uint(value_size, sizeof(__u32)); } jmp_table SEC(".maps"); int count = 0; static __noinline int subprog_tail(struct __sk_buff *skb) { bpf_tail_call_static(skb, &jmp_table, 0); return 0; } SEC("tc") int entry(struct __sk_buff *skb) { int ret = 1; count++; subprog_tail(skb); subprog_tail(skb); return ret; } When bpftool p d j id 42: int entry(struct __sk_buff * skb): bpf_prog_0c0f4c2413ef19b1_entry: ; int entry(struct __sk_buff *skb) 0: endbr64 4: nopl (%rax,%rax) 9: xorq %rax, %rax ;; rax = 0 (tail_call_cnt) c: pushq %rbp d: movq %rsp, %rbp 10: endbr64 14: cmpq $33, %rax ;; if rax > 33, rax = tcc_ptr 18: ja 0x20 ;; if rax > 33 goto 0x20 ---+ 1a: pushq %rax ;; [rbp - 8] = rax = 0 | 1b: movq %rsp, %rax ;; rax = rbp - 8 | 1e: jmp 0x21 ;; ---------+ | 20: pushq %rax ;; <--------|---------------+ 21: pushq %rax ;; <--------+ [rbp - 16] = rax 22: pushq %rbx ;; callee saved 23: movq %rdi, %rbx ;; rbx = skb (callee saved) ; count++; 26: movabsq $-82417199407104, %rdi 30: movl (%rdi), %esi 33: addl $1, %esi 36: movl %esi, (%rdi) ; subprog_tail(skb); 39: movq %rbx, %rdi ;; rdi = skb 3c: movq -16(%rbp), %rax ;; rax = tcc_ptr 43: callq 0x80 ;; call subprog_tail() ; subprog_tail(skb); 48: movq %rbx, %rdi ;; rdi = skb 4b: movq -16(%rbp), %rax ;; rax = tcc_ptr 52: callq 0x80 ;; call subprog_tail() ; return ret; 57: movl $1, %eax 5c: popq %rbx 5d: leave 5e: retq int subprog_tail(struct __sk_buff * skb): bpf_prog_3a140cef239a4b4f_subprog_tail: ; int subprog_tail(struct __sk_buff *skb) 0: endbr64 4: nopl (%rax,%rax) 9: nopl (%rax) ;; do not touch tail_call_cnt c: pushq %rbp d: movq %rsp, %rbp 10: endbr64 14: pushq %rax ;; [rbp - 8] = rax (tcc_ptr) 15: pushq %rax ;; [rbp - 16] = rax (tcc_ptr) 16: pushq %rbx ;; callee saved 17: pushq %r13 ;; callee saved 19: movq %rdi, %rbx ;; rbx = skb ; asm volatile("r1 = %[ctx]\n\t" 1c: movabsq $-105487587488768, %r13 ;; r13 = jmp_table 26: movq %rbx, %rdi ;; 1st arg, skb 29: movq %r13, %rsi ;; 2nd arg, jmp_table 2c: xorl %edx, %edx ;; 3rd arg, index = 0 2e: movq -16(%rbp), %rax ;; rax = [rbp - 16] (tcc_ptr) 35: cmpq $33, (%rax) 39: jae 0x4e ;; if *tcc_ptr >= 33 goto 0x4e --------+ 3b: jmp 0x4e ;; jmp bypass, toggled by poking | 40: addq $1, (%rax) ;; (*tcc_ptr)++ | 44: popq %r13 ;; callee saved | 46: popq %rbx ;; callee saved | 47: popq %rax ;; undo rbp-16 push | 48: popq %rax ;; undo rbp-8 push | 49: nopl (%rax,%rax) ;; tail call target, toggled by poking | ; return 0; ;; | 4e: popq %r13 ;; restore callee saved <--------------+ 50: popq %rbx ;; restore callee saved 51: leave 52: retq Furthermore, when trampoline is the caller of bpf prog, which is tail_call_reachable, it is required to propagate rax through trampoline. Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Fixes: e411901c0b77 ("bpf: allow for tailcalls in BPF subprograms for x64 JIT") Reviewed-by: Eduard Zingerman <[email protected]> Signed-off-by: Leon Hwang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]>
2024-07-29arm64: dts: rockchip: Add sdmmc/sdio/emmc reset controls for RK3328Alex Bee1-0/+6
The DW MCI controller driver will use them to reset the IP block before initialisation. Fixes: d717f7352ec6 ("arm64: dts: rockchip: add sdmmc/sdio/emmc nodes for RK3328 SoCs") Signed-off-by: Alex Bee <[email protected]> Signed-off-by: Diederik de Haas <[email protected]> Reviewed-by: Dragan Simic <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: Add sdmmc_ext for RK3328Alex Bee1-0/+14
RK3328 SoC has a fourth mmc controller called SDMMC_EXT. Some boards have sdio wifi connected to it. In order to use it one would have to add the pinctrls from sdmmc0ext group which is done on board level. Signed-off-by: Alex Bee <[email protected]> Signed-off-by: Diederik de Haas <[email protected]> Reviewed-by: Dragan Simic <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for ROCK Pi EFUKAUMI Naoki1-1/+1
use GPIO0_A2 as PMIC interrupt pin in pinctrl. (I forgot to fix this part in previous commit.) Fixes: 02afd3d5b9fa ("arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E") Signed-off-by: FUKAUMI Naoki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29ARM: dts: rockchip: use constant for HCLK_SFC on rk3128Heiko Stuebner1-1/+1
Due to inter-branch dependencies, it was necessary to add the rk3128 sfc controller with its hclk_sfc using the numeric clock id value instead of the nicer constant from the binding. Now that it's available, change over to this constant. Signed-off-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: Remove broken tsadc pinctrl binding for rk356xAlexander Shiyan1-4/+3
There is no pinctrl "init" handling in the tsadc driver. Let's remove this binding. Signed-off-by: Alexander Shiyan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: Enable UHS-I SDR-50 for Lunzn FastRhino R66SChukun Pan1-1/+1
This board can work in UHS-I SDR-104 mode, but may not be stable, use SDR-50 instead. Remove the max-frequency property, which is already defined in rk356x.dtsi. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: remove useless tx/rx_delay for Lunzn Fastrhino R68SChukun Pan1-4/+0
Since we use rgmii-id as the phy mode, remove the useless tx_delay and rx_delay properties. Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: use generic Ethernet PHY reset bindings for Lunzn ↵Chukun Pan1-8/+6
Fastrhino R68S Replace the deprecated snps,reset-xxx bindings to the generic Ethernet PHY reset GPIO bindings. According to the PHY datasheet, the RTL8211F PHY needs a 10ms assert delay and at least 72ms deassert delay. Considering the possibility of mixed use of PHY chips, increased the reset time. Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: Correct the Pinebook Pro battery design capacityDragan Simic1-1/+1
All batches of the Pine64 Pinebook Pro, except the latest batch (as of 2024) whose hardware design was revised due to the component shortage, use a 1S lithium battery whose nominal/design capacity is 10,000 mAh, according to the battery datasheet. [1][2] Let's correct the design full-charge value in the Pinebook Pro board dts, to improve the accuracy of the hardware description, and to hopefully improve the accuracy of the fuel gauge a bit on all units that don't belong to the latest batch. The above-mentioned latest batch uses a different 1S lithium battery with a slightly lower capacity, more precisely 9,600 mAh. To make the fuel gauge work reliably on the latest batch, a sample battery would need to be sent to CellWise, to obtain its proprietary battery profile, whose data goes into "cellwise,battery-profile" in the Pinebook Pro board dts. Without that data, the fuel gauge reportedly works unreliably, so changing the design capacity won't have any negative effects on the already unreliable operation of the fuel gauge in the Pinebook Pros that belong to the latest batch. According to the battery datasheet, its voltage can go as low as 2.75 V while discharging, but it's better to leave the current 3.0 V value in the dts file, because of the associated Pinebook Pro's voltage regulation issues. [1] https://wiki.pine64.org/index.php/Pinebook_Pro#Battery [2] https://files.pine64.org/doc/datasheet/pinebook/40110175P%203.8V%2010000mAh%E8%A7%84%E6%A0%BC%E4%B9%A6-14.pdf Fixes: c7c4d698cd28 ("arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts") Cc: [email protected] Cc: Marek Kraus <[email protected]> Signed-off-by: Dragan Simic <[email protected]> Link: https://lore.kernel.org/r/731f8ef9b1a867bcc730d19ed277c8c0534c0842.1721065172.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: add Firefly JD4 baseboard with Core-PX30-JD4 SoMChristopher Obbard2-0/+180
The Firefly MB-PX30-JD4 is a baseboard for the Core-PX30-JD4 SoM. Signed-off-by: Christopher Obbard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29arm64: dts: rockchip: add Firefly Core-PX30-JD4 SoMChristopher Obbard1-0/+320
The Firefly Core-PX30-JD4 SoM is a 69.6x49.6mm (260 pin SODIMM connector) system-on-module from Firefly, featuring the Rockchip PX30. It provides the following feature set: * on-module DDR3 (1GB/2GB) * on-module eMMC 5.1 (8GB/16GB/32GB/64GB/128GB) * on-module NPU (optional) * SD card (on a baseboard) via edge connector * 100mbps Ethernet (on a baseboard) via edge connector * MIPI-DSI (on a baseboard) via edge connector * Audio (on a baseboard) via edge connector - 1x SPDIF - 1x 8-channel I2S/TDM - 1x 2-channel I2S/TDM - 1x 8-channel PDM * USB (on a baseboard) via edge connector - 1x USB 2.0 OTG - 1x USB 2.0 host * Various GPIO (on a baseboard) via edge connector Signed-off-by: Christopher Obbard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]>
2024-07-29Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linuxLinus Torvalds13-26/+36
Pull ARM updates from Russell King: - ftrace: don't assume stack frames are contiguous in memory - remove unused mod_inwind_map structure - spelling fixes - allow use of LD dead code/data elimination - fix callchain_trace() return value - add support for stackleak gcc plugin - correct some reset asm function prototypes for CFI [ Missed the merge window because Russell forgot to push out ] * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9408/1: mm: CFI: Fix some erroneous reset prototypes ARM: 9407/1: Add support for STACKLEAK gcc plugin ARM: 9406/1: Fix callchain_trace() return value ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION ARM: 9403/1: Alpine: Spelling s/initialiing/initializing/ ARM: 9402/1: Kconfig: Spelling s/Cortex A-/Cortex-A/ ARM: 9400/1: Remove unused struct 'mod_unwind_map'
2024-07-29parisc: fix a possible DMA corruptionMikulas Patocka2-1/+11
ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Helge Deller <[email protected]>
2024-07-29parisc: fix unaligned accesses in BPFMikulas Patocka1-1/+1
There were spurious unaligned access warnings when calling BPF code. Sometimes, the warnings were triggered with any incoming packet, making the machine hard to use. The reason for the warnings is this: on parisc64, pointers to functions are not really pointers to functions, they are pointers to 16-byte descriptor. The first 8 bytes of the descriptor is a pointer to the function and the next 8 bytes of the descriptor is the content of the "dp" register. This descriptor is generated in the function bpf_jit_build_prologue. The problem is that the function bpf_int_jit_compile advertises 4-byte alignment when calling bpf_jit_binary_alloc, bpf_jit_binary_alloc randomizes the returned array and if the array happens to be not aligned on 8-byte boundary, the descriptor generated in bpf_jit_build_prologue is also not aligned and this triggers the unaligned access warning. Fix this by advertising 8-byte alignment on parisc64 when calling bpf_jit_binary_alloc. Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Helge Deller <[email protected]>
2024-07-29x86/aperfmperf: Fix deadlock on cpu_hotplug_lockJonathan Cameron1-2/+4
The broken patch results in a call to init_freq_invariance_cppc() in a CPU hotplug handler in both the path for initially present CPUs and those hotplugged later. That function includes a one time call to amd_set_max_freq_ratio() which in turn calls freq_invariance_enable() that has a static_branch_enable() which takes the cpu_hotlug_lock which is already held. Avoid the deadlock by using static_branch_enable_cpuslocked() as the lock will always be already held. The equivalent path on Intel does not already hold this lock, so take it around the call to freq_invariance_enable(), which results in it being held over the call to register_syscall_ops, which looks to be safe to do. Fixes: c1385c1f0ba3 ("ACPI: processor: Simplify initial onlining to use same path for cold and hotplug") Closes: https://lore.kernel.org/all/CABXGCsPvqBfL5hQDOARwfqasLRJ_eNPBbCngZ257HOe=xbWDkA@mail.gmail.com/ Reported-by: Mikhail Gavrilov <[email protected]> Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Tested-by: Mikhail Gavrilov <[email protected]> Tested-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-29arm64: dts: exynos: gs101: add syscon-poweroff and syscon-reboot nodesPeter Griffin1-0/+15
Reboot of gs101 SoC can be handled by setting the bit(SWRESET_SYSTEM[1]) of SYSTEM_CONFIGURATION register(PMU + 0x3a00). Poweroff of gs101 SoC can be handled by setting bit(DATA[8]) of PAD_CTRL_PWR_HOLD register (PMU + 0x3e9c). Tested using "reboot" and "poweroff -p" commands. Tested-by: Will McVicker <[email protected]> Signed-off-by: Peter Griffin <[email protected]> Reviewed-by: Will McVicker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-07-29arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GBDavid Virag1-1/+1
All known jackpotlte variants have 4GB of RAM, let's use it all. RAM was set to 3GB from a mistake in the vendor provided DTS file. Fixes: 06874015327b ("arm64: dts: exynos: Add initial device tree support for Exynos7885 SoC") Signed-off-by: David Virag <[email protected]> Reviewed-by: Sam Protsenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-07-29ARM: s3c: Drop explicit initialization of struct i2c_device_id::driver_data to 0Uwe Kleine-König1-1/+1
The wlf-gf-module driver doesn't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-07-29Merge tag 'ti-k3-dt-for-v6.11-part2' into ti-k3-dts-nextNishanth Menon1-17/+8
Late fixes towards v6.11-rc1 First patch fixes warning splat seen on J784S4 due to overlapping serdes0 lane. Second patch cleans up the serdes0 references for readability Signed-off-by: Nishanth Menon <[email protected]>
2024-07-29perf/x86: Add hw_perf_event::aux_configPeter Zijlstra1-7/+7
Start a new section for AUX PMUs in hw_perf_event. Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
2024-07-29perf/x86/intel/pt: Fix sampling synchronizationAdrian Hunter1-8/+7
pt_event_snapshot_aux() uses pt->handle_nmi to determine if tracing needs to be stopped, however tracing can still be going because pt->handle_nmi is set to zero before tracing is stopped in pt_event_stop, whereas pt_event_snapshot_aux() requires that tracing must be stopped in order to copy a sample of trace from the buffer. Instead call pt_config_stop() always, which anyway checks config for RTIT_CTL_TRACEEN and does nothing if it is already clear. Note pt_event_snapshot_aux() can continue to use pt->handle_nmi to determine if the trace needs to be restarted afterwards. Fixes: 25e8920b301c ("perf/x86/intel/pt: Add sampling support") Signed-off-by: Adrian Hunter <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected]
2024-07-29perf/x86/intel/cstate: Add pkg C2 residency counter for Sierra ForestZhenyu Wang1-2/+3
Package C2 residency counter is also available on Sierra Forest. So add it support in srf_cstates. Fixes: 3877d55a0db2 ("perf/x86/intel/cstate: Add Sierra Forest support") Signed-off-by: Zhenyu Wang <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Kan Liang <[email protected]> Tested-by: Wendy Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-07-29arm64: defconfig: Enable AK4619 codec supportKuninori Morimoto1-0/+1
Enable AK4619 audio codec support, as used on the Gray Hawk Single development board. Signed-off-by: Kuninori Morimoto <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-07-29arm64: dts: renesas: gray-hawk-single: Add GP LEDsGeert Uytterhoeven1-0/+26
Describe the three General Purpose LEDs on the Gray Hawk Single board, so they can be used as indicator LEDs. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/408eac88ec61cf4c56c96397fbb93b4b8c2c8f5b.1721649057.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: gray-hawk-single: Add push switchesGeert Uytterhoeven1-0/+37
Describe the three Push Switches on the Gray Hawk Single board, so they can be used for user input. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/41b8277d4b630e0c296375888d9b958448d02cde.1721649057.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a779h0: Add missing iommus propertiesGeert Uytterhoeven1-0/+2
Add missing iommus properties to all EthernetAVB device nodes that still lack them. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/1ed05b12961662e8fed2f1a6790f5ae3b595f509.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a779g0: Add missing iommus propertiesGeert Uytterhoeven1-0/+5
Add missing iommus properties to all EthernetAVB and Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/bd394a7e330610d76d98cd5d230c0b3fcbf5c3e4.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a779a0: Add missing iommus propertiesGeert Uytterhoeven1-0/+20
Add missing iommus properties to all EthernetAVB, DMAC, and Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/39da0dddf7e7f1fde2b2d83444af7bb5ae73b922.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a77980: Add missing iommus propertiesGeert Uytterhoeven1-0/+2
Add missing iommus properties to the Gigabit Ethernet and Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/3259f4906e20ea626dcd45b7dd310155570b399c.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a77970: Add missing iommus propertyGeert Uytterhoeven1-0/+1
Add the missing iommus property to the Frame Compression Processor device node. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/41445bdf72a40c9deb36b88e8360b50eb2836919.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a77965: Add missing iommus propertiesGeert Uytterhoeven1-0/+22
Add missing iommus properties to all Audio-DMAC, Serial-ATA, and Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/79fe31020799ba508d16ff8dbd4296f239ecf76a.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a77961: Add missing iommus propertiesGeert Uytterhoeven1-0/+2
Add missing iommus properties to Frame Compression Processor device nodes that still lack them. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/25f8764edcb4f83f4dc3acfae36fa1fcbfd10cd7.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a77960: Add missing iommus propertiesGeert Uytterhoeven1-0/+2
Add missing iommus properties to Frame Compression Processor device nodes that still lack them. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/21e6b8dc21d8f1605d1cf5f081811b55e33ce04d.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a774e1: Add missing iommus propertiesGeert Uytterhoeven1-0/+8
Add missing iommus properties to all Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/b2a1a5fd41c78c881e6e410b720e5e12572e2668.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a774c0: Add missing iommus propertiesGeert Uytterhoeven1-0/+3
Add missing iommus properties to all SDHI device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/299b47bf40d4d2d44beff46b3323c471915c714d.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a774b1: Add missing iommus propertiesGeert Uytterhoeven1-0/+26
Add missing iommus properties to all Audio-DMAC, SDHI, Serial-ATA, and Frame Compression Processor device nodes. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/2d6a97d2df0532c661a2be6bafc9e5061c645197.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: r8a774a1: Add missing iommus propertiesGeert Uytterhoeven1-0/+6
Add missing iommus properties to SDHI and Frame Compression Processor device nodes that still lack them. Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/114e9915356670e59dae412c1054afad4ce4c964.1720430758.git.geert+renesas@glider.be
2024-07-29arm64: dts: renesas: gray-hawk-single: Add Sound supportKuninori Morimoto1-0/+108
Because R-Car V4M supports only 1 SSI, it cannot use Playback/Capture at the same time. Hence select Playback as default. Signed-off-by: Kuninori Morimoto <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-07-29x86/elf: Add a new FPU buffer layout info to x86 core filesVignesh Balasubramanian3-0/+106
Add a new .note section containing type, size, offset and flags of every xfeature that is present. This information will be used by debuggers to understand the XSAVE layout of the machine where the core file has been dumped, and to read XSAVE registers, especially during cross-platform debugging. The XSAVE layouts of modern AMD and Intel CPUs differ, especially since Memory Protection Keys and the AVX-512 features have been inculcated into the AMD CPUs. Since AMD never adopted (and hence never left room in the XSAVE layout for) the Intel MPX feature, tools like GDB had assumed a fixed XSAVE layout matching that of Intel (based on the XCR0 mask). Hence, core dumps from AMD CPUs didn't match the known size for the XCR0 mask. This resulted in GDB and other tools not being able to access the values of the AVX-512 and PKRU registers on AMD CPUs. To solve this, an interim solution has been accepted into GDB, and is already a part of GDB 14, see https://sourceware.org/pipermail/gdb-patches/2023-March/198081.html. But it depends on heuristics based on the total XSAVE register set size and the XCR0 mask to infer the layouts of the various register blocks for core dumps, and hence, is not a foolproof mechanism to determine the layout of the XSAVE area. Therefore, add a new core dump note in order to allow GDB/LLDB and other relevant tools to determine the layout of the XSAVE area of the machine where the corefile was dumped. The new core dump note (which is being proposed as a per-process .note section), NT_X86_XSAVE_LAYOUT (0x205) contains an array of structures. Each structure describes an individual extended feature containing offset, size and flags in this format: struct x86_xfeat_component { u32 type; u32 size; u32 offset; u32 flags; }; and in an independent manner, allowing for future extensions without depending on hw arch specifics like CPUID etc. [ bp: Massage commit message, zap trailing whitespace. ] Co-developed-by: Jini Susan George <[email protected]> Signed-off-by: Jini Susan George <[email protected]> Co-developed-by: Borislav Petkov (AMD) <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Signed-off-by: Vignesh Balasubramanian <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.