summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-09hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerHyunwoo Kim
When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL. Signed-off-by: Hyunwoo Kim <v4bel@theori.io> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/Zys4hCj61V+mQfX2@v4bel-B760M-AORUS-ELITE-AX Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09net: sfc: use ethtool string helpersRosen Penev
The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Cleans up the code quite well. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20241105231855.235894-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09mptcp: remove the redundant assignment of 'new_ctx->tcp_sock' in ↵MoYuanhao
subflow_ulp_clone() The variable has already been assigned in the subflow_create_ctx(), So we don't need to reassign this variable in the subflow_ulp_clone(). Signed-off-by: MoYuanhao <moyuanhao3676@163.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20241106071035.2591-1-moyuanhao3676@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09net: mctp: Expose transport binding identifier via IFLA attributeKhang Nguyen
MCTP control protocol implementations are transport binding dependent. Endpoint discovery is mandatory based on transport binding. Message timing requirements are specified in each respective transport binding specification. However, we currently have no means to get this information from MCTP links. Add a IFLA_MCTP_PHYS_BINDING netlink link attribute, which represents the transport type using the DMTF DSP0239-defined type numbers, returned as part of RTM_GETLINK data. We get an IFLA_MCTP_PHYS_BINDING attribute for each MCTP link, for example: - 0x00 (unspec) for loopback interface; - 0x01 (SMBus/I2C) for mctpi2c%d interfaces; and - 0x05 (serial) for mctpserial%d interfaces. Signed-off-by: Khang Nguyen <khangng@os.amperecomputing.com> Reviewed-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20241105071915.821871-1-khangng@os.amperecomputing.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09scftorture: Use a lock-less list to free memory.Sebastian Andrzej Siewior
scf_handler() is used as a SMP function call. This function is always invoked in IRQ-context even with forced-threading enabled. This function frees memory which not allowed on PREEMPT_RT because the locking underneath is using sleeping locks. Add a per-CPU scf_free_pool where each SMP functions adds its memory to be freed. This memory is then freed by scftorture_invoker() on each iteration. On the majority of invocations the number of items is less than five. If the thread sleeps/ gets delayed the number exceed 350 but did not reach 400 in testing. These were the spikes during testing. The bulk free of 64 pointers at once should improve the give-back if the list grows. The list size is ~1.3 items per invocations. Having one global scf_free_pool with one cleaning thread let the list grow to over 10.000 items with 32 CPUs (again, spikes not the average) especially if the CPU went to sleep. The per-CPU part looks like a good compromise. Reported-by: "Paul E. McKenney" <paulmck@kernel.org> Closes: https://lore.kernel.org/lkml/41619255-cdc2-4573-a360-7794fc3614f7@paulmck-laptop/ Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Move memory allocation outside of preempt_disable region.Sebastian Andrzej Siewior
Memory allocations can not happen within regions with explicit disabled preemption PREEMPT_RT. The problem is that the locking structures underneath are sleeping locks. Move the memory allocation outside of the preempt-disabled section. Keep the GFP_ATOMIC for the allocation to behave like a "ememergncy allocation". Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Wait until scf_cleanup_handler() completes.Sebastian Andrzej Siewior
The smp_call_function() needs to be invoked with the wait flag set to wait until scf_cleanup_handler() is done. This ensures that all SMP function calls, that have been queued earlier, complete at this point. Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09scftorture: Avoid additional div operation.Sebastian Andrzej Siewior
Replace "scfp->cpu % nr_cpu_ids" with "cpu". This has been computed earlier. Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2024-11-09sched_ext: add a missing rcu_read_lock/unlock pair at scx_select_cpu_dfl()Changwoo Min
When getting an LLC CPU mask in the default CPU selection policy, scx_select_cpu_dfl(), a pointer to the sched_domain is dereferenced using rcu_read_lock() without holding rcu_read_lock(). Such an unprotected dereference often causes the following warning and can cause an invalid memory access in the worst case. Therefore, protect dereference of a sched_domain pointer using a pair of rcu_read_lock() and unlock(). [ 20.996135] ============================= [ 20.996345] WARNING: suspicious RCU usage [ 20.996563] 6.11.0-virtme #17 Tainted: G W [ 20.996576] ----------------------------- [ 20.996576] kernel/sched/ext.c:3323 suspicious rcu_dereference_check() usage! [ 20.996576] [ 20.996576] other info that might help us debug this: [ 20.996576] [ 20.996576] [ 20.996576] rcu_scheduler_active = 2, debug_locks = 1 [ 20.996576] 4 locks held by kworker/8:1/140: [ 20.996576] #0: ffff8b18c00dd348 ((wq_completion)pm){+.+.}-{0:0}, at: process_one_work+0x4a0/0x590 [ 20.996576] #1: ffffb3da01f67e58 ((work_completion)(&dev->power.work)){+.+.}-{0:0}, at: process_one_work+0x1ba/0x590 [ 20.996576] #2: ffffffffa316f9f0 (&rcu_state.gp_wq){..-.}-{2:2}, at: swake_up_one+0x15/0x60 [ 20.996576] #3: ffff8b1880398a60 (&p->pi_lock){-.-.}-{2:2}, at: try_to_wake_up+0x59/0x7d0 [ 20.996576] [ 20.996576] stack backtrace: [ 20.996576] CPU: 8 UID: 0 PID: 140 Comm: kworker/8:1 Tainted: G W 6.11.0-virtme #17 [ 20.996576] Tainted: [W]=WARN [ 20.996576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 20.996576] Workqueue: pm pm_runtime_work [ 20.996576] Sched_ext: simple (disabling+all), task: runnable_at=-6ms [ 20.996576] Call Trace: [ 20.996576] <IRQ> [ 20.996576] dump_stack_lvl+0x6f/0xb0 [ 20.996576] lockdep_rcu_suspicious.cold+0x4e/0x96 [ 20.996576] scx_select_cpu_dfl+0x234/0x260 [ 20.996576] select_task_rq_scx+0xfb/0x190 [ 20.996576] select_task_rq+0x47/0x110 [ 20.996576] try_to_wake_up+0x110/0x7d0 [ 20.996576] swake_up_one+0x39/0x60 [ 20.996576] rcu_core+0xb08/0xe50 [ 20.996576] ? srso_alias_return_thunk+0x5/0xfbef5 [ 20.996576] ? mark_held_locks+0x40/0x70 [ 20.996576] handle_softirqs+0xd3/0x410 [ 20.996576] irq_exit_rcu+0x78/0xa0 [ 20.996576] sysvec_apic_timer_interrupt+0x73/0x80 [ 20.996576] </IRQ> [ 20.996576] <TASK> [ 20.996576] asm_sysvec_apic_timer_interrupt+0x1a/0x20 [ 20.996576] RIP: 0010:_raw_spin_unlock_irqrestore+0x36/0x70 [ 20.996576] Code: f5 53 48 8b 74 24 10 48 89 fb 48 83 c7 18 e8 11 b4 36 ff 48 89 df e8 99 0d 37 ff f7 c5 00 02 00 00 75 17 9c 58 f6 c4 02 75 2b <65> ff 0d 5b 55 3c 5e 74 16 5b 5d e9 95 8e 28 00 e8 a5 ee 44 ff 9c [ 20.996576] RSP: 0018:ffffb3da01f67d20 EFLAGS: 00000246 [ 20.996576] RAX: 0000000000000002 RBX: ffffffffa4640220 RCX: 0000000000000040 [ 20.996576] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa1c7b27b [ 20.996576] RBP: 0000000000000246 R08: 0000000000000001 R09: 0000000000000000 [ 20.996576] R10: 0000000000000001 R11: 000000000000021c R12: 0000000000000246 [ 20.996576] R13: ffff8b1881363958 R14: 0000000000000000 R15: ffff8b1881363800 [ 20.996576] ? _raw_spin_unlock_irqrestore+0x4b/0x70 [ 20.996576] serial_port_runtime_resume+0xd4/0x1a0 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] __rpm_callback+0x44/0x170 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] rpm_callback+0x55/0x60 [ 20.996576] ? __pfx_serial_port_runtime_resume+0x10/0x10 [ 20.996576] rpm_resume+0x582/0x7b0 [ 20.996576] pm_runtime_work+0x7c/0xb0 [ 20.996576] process_one_work+0x1fb/0x590 [ 20.996576] worker_thread+0x18e/0x350 [ 20.996576] ? __pfx_worker_thread+0x10/0x10 [ 20.996576] kthread+0xe2/0x110 [ 20.996576] ? __pfx_kthread+0x10/0x10 [ 20.996576] ret_from_fork+0x34/0x50 [ 20.996576] ? __pfx_kthread+0x10/0x10 [ 20.996576] ret_from_fork_asm+0x1a/0x30 [ 20.996576] </TASK> [ 21.056592] sched_ext: BPF scheduler "simple" disabled (unregistered from user space) Signed-off-by: Changwoo Min <changwoo@igalia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-09gpio: Get rid of GPIOF_ACTIVE_LOWAndy Shevchenko
No more users. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-7-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09USB: gadget: pxa27x_udc: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-6-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09pcmcia: soc_common: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Dominik Brodowski <linux@dominikbrodowski.net> Link: https://lore.kernel.org/r/20241104093609.156059-5-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09leds: gpio: Avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Lee Jones <lee@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-4-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09Input: gpio_keys_polled - avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09Input: gpio_keys - avoid using GPIOF_ACTIVE_LOWAndy Shevchenko
Avoid using GPIOF_ACTIVE_LOW as it's deprecated and subject to remove. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241104093609.156059-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-09media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in ↵Benoit Sevens
uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Signed-off-by: Benoit Sevens <bsevens@google.com> Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2024-11-09arm64: dts: rockchip: Enable HDMI0 on FriendlyElec CM3588 NASJonas Karlman
Add the necessary DT changes to enable HDMI0 on FriendlyElec CM3588 NAS. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20241108171423.835496-1-jonas@kwiboo.se Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: add Banana Pi P2 Pro boardDmitry Yashin
Banana Pi P2 Pro is the SBC made by Shenzhen SINOVOIP based on Rockchip RK3308. Banana Pi P2 Pro features: - Rockchip RK3308B-S - DDR3 512 MB - eMMC 8 GB - 100M lan + onboard PoE - 40 pin and 12 pin headers - AP6256 BT + WIFI - TF card slot - 2x USB 2.0 (Type-C OTG and Type-A) - Headphone jack Add support for Banana Pi P2 Pro. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> Link: https://lore.kernel.org/r/20241030202144.629956-3-dmt.yashin@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09dt-bindings: arm: rockchip: add Banana Pi P2 Pro boardDmitry Yashin
BBanana Pi P2 Pro is the SBC made by Shenzhen SINOVOIP based on Rockchip RK3308. Banana Pi P2 Pro features: - Rockchip RK3308B-S - DDR3 512 MB - eMMC 8 GB - 100M lan + onboard PoE - 40 pin and 12 pin headers - AP6256 BT + WIFI - TF card slot - 2x USB 2.0 (Type-C OTG and Type-A) - Headphone jack Add devicetree binding for Banana Pi P2 Pro. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241030202144.629956-2-dmt.yashin@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Add new SoC dtsi for the RK3566T variantDragan Simic
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC. The difference between the RK3566T variant and the "full-fat" RK3566 variant is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of a functional NPU, which we currently don't have to worry about. Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero SBC, [1] which is yet to be supported, the Radxa ROCK 3C, and the Radxa ZERO 3E/3W SBCs, which are both already supported. Though, Radxa doesn't mention the use of RK3566T officially, but its official SBC specifications do state that the maximum frequency for the Cortex-A55 cores on those SBCs is lower than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of the RK3566T SoC variant rather easy. [2][3][4] An additional, helpful cue is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately in its downstream kernel source. [5] The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the vendor kernel source, [6] which uses the values of the "opp-supported-hw" OPP properties to determine which ones are supported on a particular SoC variant. The actual values of the "opp-supported-hw" properties make it rather easy to see what OPPs are supported on the RK3566T SoC variant, but that, rather unfortunately, clashes with the maximum frequencies advertised officially for the Cortex-A55 CPU cores on the above-mentioned SBCs. [1][2][3][4] The vendor kernel source indicates that the maximum frequency for the CPU cores is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Until that discrepancy is resolved somehow, let's take the safe approach and use the lower maximum frequency for the CPU cores. Update the dts files of the currently supported RK3566T-based boards to use the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores and the GPUs found on these boards out of their earlier overclocks, but it also means that the officially advertised specifications [1][2][3][4] of the highest supported frequencies for the Cortex-A55 CPU cores on these boards may actually be wrong, as already explained above. The correctness of the introduced changes was validated by decompiling and comparing all affected board dtb files before and after these changes. [1] https://wiki.pine64.org/wiki/Quartz64 [2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf [3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf [4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf [5] https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8 [6] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Cc: TL Lim <tllim@pine64.org> Cc: Marek Kraus <gamiee@pine64.org> Cc: Tom Cubie <tom@radxa.com> Cc: FUKAUMI Naoki <naoki@radxa.com> Helped-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Helped-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/a85b9bdc176c542fea261fe7ef37697aebb42e8b.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Prepare RK356x SoC dtsi files for per-variant OPPsDragan Simic
Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their contents appropriately, to prepare them for the ability to specify different CPU and GPU OPPs for each of the supported RK356x SoC variants. The first new RK356x SoC variant to be introduced is the RK3566T, which the Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W, but the slight trouble is that Radxa doesn't state that officially. Though, it's rather easy to spot the RK3566T on such boards, because their official specifications state that the maximum frequency for the Cortex-A55 cores is lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4] These changes follow the approach used for the Rockchip RK3588 SoC variants, which was introduced and described further in commit def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please see that commit for a more detailed explanation. No functional changes are introduced, which was validated by decompiling and comparing all affected board dtb files before and after these changes. In more detail, the affected dtb files have some of their blocks shuffled around a bit and some of their phandles have different values, as a result of the changes to the order in which the building blocks from the parent dtsi files are included, but they effectively remain the same as the originals. As a side note, due to the nature of introduced changes, this commit is a bit more readable when viewed using the --break-rewrites option for git-log(1). [1] https://wiki.pine64.org/wiki/Quartz64 [2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf [3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf [4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf Related-to: def88eb4d836 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/77e7450b8280bbdf4e2dc47366c9da85d4d8d1de.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Update CPU OPP voltages in RK356x SoC dtsiDragan Simic
Update the lower/upper voltage limits and the exact voltages for the Rockchip RK356x CPU OPPs, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source. [1] Using the most conservative per-OPP voltages ensures reliable CPU operation regardless of the actual CPU binning, with the downside of possibly using a bit more power for the CPU cores than absolutely needed. Additionally, fill in the missing "clock-latency-ns" CPU OPP properties, using the values found in the vendor kernel source. [1] [1] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi Related-to: eb665b1c06bc ("arm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/f816cd24b62742dd05a1b7c6fe162bb581c9b3bf.1730516702.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Add OPP voltage ranges to RK3399 OP1 SoC dtsiDragan Simic
Add support for voltage ranges to the CPU, GPU and DMC OPPs defined in the SoC dtsi for Rockchip OP1, as a variant of the Rockchip RK3399. This may be useful if there are any OP1-based boards whose associated voltage regulators are unable to deliver the exact voltages; otherwise, it causes no functional changes to the resulting OPP voltages at runtime. These changes cannot cause stability issues or any kind of damage, because it's perfectly safe to use the highest voltage from an OPP group for each OPP in the same group. The only possible negative effect of using higher voltages is wasted energy in form of some additionally generated heat. Reported-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/dbee35c002bda99e44f8533623d94f202a60da95.1730881777.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Enable HDMI0 on Indiedroid NovaChris Morgan
Enable the HDMI0 port for the Indiedroid Nova. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-4-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: Enable GPU on Indiedroid NovaChris Morgan
Enable the GPU for the Indiedroid Nova. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-3-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: correct analog audio name on Indiedroid NovaChris Morgan
Correct the audio name for the Indiedroid Nova from rockchip,es8388-codec to rockchip,es8388. This name change corrects a kernel log error of "ASoC: driver name too long 'rockchip,es8388-codec' -> 'rockchip_es8388'". Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-09arm64: dts: rockchip: sort rk3588s-rock5a properly in MakefileFUKAUMI Naoki
sort target dtb files properly in Makefile for rockchip. Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20241028072344.1514-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-11-08sched_ext: Clarify sched_ext_ops table for userland schedulerChangwoo Min
Update the comments in sched_ext_ops to clarify this table is for a BPF scheduler and a userland scheduler should also rely on the sched_ext_ops table through the BPF scheduler. Signed-off-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-09ASoC: stm32: i2s: add stm32mp25 supportMark Brown
Merge series from Olivier Moysan <olivier.moysan@foss.st.com>: Update STM32 I2S driver and binding to support STM32MP25 SoCs.
2024-11-09ASoC: stm32: sai: add stm32mp25 supportMark Brown
Merge series from Olivier Moysan <olivier.moysan@foss.st.com>: Update STM32 SAI driver and binding to support STM32MP25 SoCs.
2024-11-09ASoC: Intel: Fix Kconfig for ACPI=nMark Brown
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>: Hi, A recent attempt to fix a missing symbol when CONFIG_SND_SOC_SDCA=m and CONFIG_SND_SOC_ACPI_INTEL_SDCA_QUIRKS=y caused unmet direct dependency warning with randconig. The reason is that SND_SOC_ACPI_INTEL_MATCH is needed to be compilable even if ACPI is not selected, modules have dependency on exported symbols from it. The only solution for these kconfig dependencies seams to be to only select SND_SOC_SDCA if ACPI is enabled from SND_SOC_ACPI_INTEL_SDCA_QUIRKS. Regards, Peter --- Peter Ujfalusi (2): ASoC: Intel: Kconfig: Only select SND_SOC_SDCA if ACPI is enabled ASoC: Intel: Kconfig: Revert make SND_SOC_ACPI_INTEL_MATCH depend on ACPI sound/soc/intel/Kconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.47.0
2024-11-09ASoC: qcom: sm8250: add handling of secondary MI2S clockAlexey Klimov
Add handling of clock related to secondary MI2S_RX in sm8250_snd_startup(). Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20241018025452.1362293-2-alexey.klimov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-08Merge tag 'thermal-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix one issue in the qcom lmh thermal driver, a DT handling issue in the thermal core and two issues in the userspace thermal library: - Allow tripless thermal zones defined in a DT to be registered in accordance with the thermal DT bindings (Icenowy Zheng) - Annotate LMH IRQs with lockdep classes to prevent lockdep from reporting a possible recursive locking issue that cannot really occur (Dmitry Baryshkov) - Improve the thermal library "make clean" to remove a leftover symbolic link created during compilation and fix the sampling handler invocation in that library to pass the correct pointer to it (Emil Dahl Juhl, zhang jiao)" * tag 'thermal-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal/of: support thermal zones w/o trips subnode tools/lib/thermal: Remove the thermal.h soft link when doing make clean tools/lib/thermal: Fix sampling handler context ptr thermal/drivers/qcom/lmh: Remove false lockdep backtrace
2024-11-08Merge tag 'pm-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix the asymmetric CPU capacity support code in the intel_pstate driver, added during this develompent cycle, to address a corner case in which the capacity of a CPU going online is not updated (Rafael Wysocki)" * tag 'pm-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Update asym capacity for CPUs that were offline initially cpufreq: intel_pstate: Clear hybrid_max_perf_cpu before driver registration
2024-11-08Merge tag 'acpi-6.12-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Fix the ACPI processor driver initialization ordering after recent changes to avoid calling init_freq_invariance_cppc() too early on AMD platforms (Mario Limonciello)" * tag 'acpi-6.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor: Move arch_init_invariance_cppc() call later
2024-11-08Merge tag 'v6.12-rc6-ksmbd-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull smb server fixes from Steve French: "Four fixes, all also marked for stable: - fix two potential use after free issues - fix OOM issue with many simultaneous requests - fix missing error check in RPC pipe handling" * tag 'v6.12-rc6-ksmbd-fixes' of git://git.samba.org/ksmbd: ksmbd: check outstanding simultaneous SMB operations ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create ksmbd: Fix the missing xa_store error check
2024-11-08EDAC/igen6: Add polling supportOrange Kao
Some PCs with Intel N100 (with PCI device 8086:461c, DID_ADL_N_SKU4) experienced issues with error interrupts not working, even with the following configuration in the BIOS. In-Band ECC Support: Enabled In-Band ECC Operation Mode: 2 (make all requests protected and ignore range checks) IBECC Error Injection Control: Inject Correctable Error on insertion counter Error Injection Insertion Count: 251658240 (0xf000000) Add polling mode support for these machines to ensure that memory error events are handled. Signed-off-by: Orange Kao <orange@aiven.io> Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Link: https://lore.kernel.org/all/20241106114024.941659-3-orange@aiven.io
2024-11-08EDAC/igen6: Initialize edac_op_state according to the configuration dataQiuxu Zhuo
Currently, igen6_edac sets edac_op_state to EDAC_OPSTATE_NMI, while the driver also supports memory errors reported from Machine Check. Initialize edac_op_state to the correct value according to the configuration data that the driver probed. Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/all/20241106114024.941659-2-orange@aiven.io
2024-11-08dt-bindings: interrupt-controller: qcom,pdc: Add SAR2130P compatibleDmitry Baryshkov
Document compatible for PDC interrupt controller on SAR2130P platform. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241017-sar2130p-pdc-v1-1-cf9ccd9c37da@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-11-08sched_ext: Enable the ops breather and eject BPF scheduler on softlockupTejun Heo
On 2 x Intel Sapphire Rapids machines with 224 logical CPUs, a poorly behaving BPF scheduler can live-lock the system by making multiple CPUs bang on the same DSQ to the point where soft-lockup detection triggers before SCX's own watchdog can take action. It also seems possible that the machine can be live-locked enough to prevent scx_ops_helper, which is an RT task, from running in a timely manner. Implement scx_softlockup() which is called when three quarters of soft-lockup threshold has passed. The function immediately enables the ops breather and triggers an ops error to initiate ejection of the BPF scheduler. The previous and this patch combined enable the kernel to reliably recover the system from live-lock conditions that can be triggered by a poorly behaving BPF scheduler on Intel dual socket systems. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org>
2024-11-08sched_ext: Avoid live-locking bypass mode switchingTejun Heo
A poorly behaving BPF scheduler can live-lock the system by e.g. incessantly banging on the same DSQ on a large NUMA system to the point where switching to the bypass mode can take a long time. Turning on the bypass mode requires dequeueing and re-enqueueing currently runnable tasks, if the DSQs that they are on are live-locked, this can take tens of seconds cascading into other failures. This was observed on 2 x Intel Sapphire Rapids machines with 224 logical CPUs. Inject artifical delays while the bypass mode is switching to guarantee timely completion. While at it, move __scx_ops_bypass_lock into scx_ops_bypass() and rename it to bypass_lock. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Valentin Andrei <vandrei@meta.com> Reported-by: Patrick Lu <patlu@meta.com>
2024-11-08bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6Jiawei Ye
In the bpf_out_neigh_v6 function, rcu_read_lock() is used to begin an RCU read-side critical section. However, when unlocking, one branch incorrectly uses a different RCU unlock flavour rcu_read_unlock_bh() instead of rcu_read_unlock(). This mismatch in RCU locking flavours can lead to unexpected behavior and potential concurrency issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. This patch corrects the mismatched unlock flavour by replacing the incorrect rcu_read_unlock_bh() with the appropriate rcu_read_unlock(), ensuring that the RCU critical section is properly exited. This change prevents potential synchronization issues and aligns with proper RCU usage patterns. Fixes: 09eed1192cec ("neighbour: switch to standard rcu, instead of rcu_bh") Signed-off-by: Jiawei Ye <jiawei.ye@foxmail.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/tencent_CFD3D1C3D68B45EA9F52D8EC76D2C4134306@qq.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2024-11-08Merge branch 'for-6.12-fixes' into for-6.13Tejun Heo
Pull sched_ext/for-6.12-fixes to receive 0e7ffff1b811 ("scx: Fix raciness in scx_ops_bypass()"). Planned updates for scx_ops_bypass() depends on it. Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-08sched_ext: Fix incorrect use of bitwise ANDAndrea Righi
There is no reason to use a bitwise AND when checking the conditions to enable NUMA optimization for the built-in CPU idle selection policy, so use a logical AND instead. Fixes: f6ce6b949304 ("sched_ext: Do not enable LLC/NUMA optimizations when domains overlap") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/lkml/20241108181753.GA2681424@thelio-3990X/ Signed-off-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-08Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two small fixes, the drivers one in ufs simply delays running a work queue and the generic one in zoned storage switches to a more correct API that tries the standard buddy allocator first (for small allocations); this fixes an allocation problem with small allocations seen under memory pressure" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Start the RTC update work later scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer
2024-11-08Merge tag 'drm-fixes-2024-11-09' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly fixes, usual leaders in amdgpu and xe, then a panel quirk, and some fixes to imagination and panthor drivers. Seems around the usual level for this time and don't know of any big problems. amdgpu: - Brightness fix - DC vbios parsing fix - ACPI fix - SMU 14.x fix - Power workload profile fix - GC partitioning fix - Debugfs fixes imagination: - Track PVR context per file - Break ref-counting cycle panel-orientation-quirks: - Fix matching Lenovo Yoga Tab 3 X90F panthor: - Lock VM array - Be strict about I/O mapping flags xe: - Fix ccs_mode setting for Xe2 and later - Synchronize ccs_mode setting with client creation - Apply scheduling WA for LNL in additional places as needed - Fix leak and lock handling in error paths of xe_exec ioctl - Fix GGTT allocation leak leading to eventual crash in SR-IOV - Move run_ticks update out of job handling to avoid synchronization with reader" * tag 'drm-fixes-2024-11-09' of https://gitlab.freedesktop.org/drm/kernel: (23 commits) drm/panthor: Be stricter about IO mapping flags drm/panthor: Lock XArray when getting entries for the VM drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less strict drm/xe: Stop accumulating LRC timestamp on job_free drm/xe/pf: Fix potential GGTT allocation leak drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL drm/xe: Fix possible exec queue leak in exec IOCTL drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() drm/amdgpu: Adjust debugfs eviction and IB access permissions drm/amdgpu: Adjust debugfs register access permissions drm/amdgpu: Fix DPX valid mode check on GC 9.4.3 drm/amd/pm: correct the workload setting drm/amd/pm: always pick the pptable from IFWI drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported drm/amd/display: parse umc_info or vram_info based on ASIC drm/amd/display: Fix brightness level not retained over reboot drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout drm/xe: Move LNL scheduling WA to xe_device.h drm/xe: Use the filelist from drm for ccs_mode change ...
2024-11-08of/address: Rework bus matching to avoid warningsRob Herring (Arm)
With warnings added for deprecated #address-cells/#size-cells handling, the DT address handling code causes warnings when used on nodes with no address. This happens frequently with calls to of_platform_populate() as it is perfectly acceptable to have devices without a 'reg' property. The desired behavior is to just silently return an error when retrieving an address. The warnings can be avoided by checking for "#address-cells" presence first and checking for an address property before fetching "#address-cells" and "#size-cells". Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Reported-by: Steven Price <steven.price@arm.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20241108193547.2647986-2-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-11-08of: WARN on deprecated #address-cells/#size-cells handlingRob Herring (Arm)
While OpenFirmware originally allowed walking parent nodes and default root values for #address-cells and #size-cells, FDT has long required explicit values. It's been a warning in dtc for the root node since the beginning (2005) and for any parent node since 2007. Of course, not all FDT uses dtc, but that should be the majority by far. The various extracted OF devicetrees I have dating back to the 1990s (various PowerMac, OLPC, PASemi Nemo) all have explicit root node properties. The warning is disabled for Sparc as there are known systems relying on default root node values. Link: https://lore.kernel.org/r/20241106171028.3830266-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-11-08of/fdt: Don't use default address cell sizes for address translationRob Herring (Arm)
FDT systems should never be relying on default cell sizes. It's been a warning in dtc since 2007. The behavior here doesn't even match the unflattened code which will walk the parent nodes looking for the cell size properties (also deprecated). Furthermore, the FDT address translation code is only used in one spot by SH and for earlycon which was added 2014 and certainly isn't used on Powerpc systems. Returning -1 values will result in an error message. Link: https://lore.kernel.org/r/20241106170808.3827790-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-11-08dt-bindings: Enable dtc "interrupt_provider" warningsRob Herring (Arm)
All the warnings from the "interrupt_provider" dtc check are fixed now, so enable the warning for the examples. Link: https://lore.kernel.org/r/20241105213232.443192-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-22 14:32:40 +0000