January 2025 - Linux-stable-mirror

[PATCH AUTOSEL 6.6 1/2] RDMA/bnxt_re: Fix to export port num to ib_query_qp

by Sasha Levin

From: Hongguang Gao <hongguang.gao(a)broadcom.com> [ Upstream commit 34db8ec931b84d1426423f263b1927539e73b397 ] Current driver implementation doesn't populate the port_num field in query_qp. Adding the code to convert internal firmware port id to ibv defined port number and export it. Reviewed-by: Saravanan Vajravel <saravanan.vajravel(a)broadcom.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil(a)broadcom.com> Signed-off-by: Hongguang Gao <hongguang.gao(a)broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier(a)broadcom.com> Link: https://patch.msgid.link/20241211083931.968831-5-kalesh-anakkur.purayil@bro… Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 1 + drivers/infiniband/hw/bnxt_re/ib_verbs.h | 4 ++++ drivers/infiniband/hw/bnxt_re/qplib_fp.c | 1 + drivers/infiniband/hw/bnxt_re/qplib_fp.h | 1 + 4 files changed, 7 insertions(+) diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c index df5897260601..5f6b1d7278da 100644 --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c @@ -2214,6 +2214,7 @@ int bnxt_re_query_qp(struct ib_qp *ib_qp, struct ib_qp_attr *qp_attr, qp_attr->retry_cnt = qplib_qp->retry_cnt; qp_attr->rnr_retry = qplib_qp->rnr_retry; qp_attr->min_rnr_timer = qplib_qp->min_rnr_timer; + qp_attr->port_num = __to_ib_port_num(qplib_qp->port_id); qp_attr->rq_psn = qplib_qp->rq.psn; qp_attr->max_rd_atomic = qplib_qp->max_rd_atomic; qp_attr->sq_psn = qplib_qp->sq.psn; diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.h b/drivers/infiniband/hw/bnxt_re/ib_verbs.h index 98baea98fc17..ef910e6e2ccb 100644 --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.h +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.h @@ -245,6 +245,10 @@ void bnxt_re_dealloc_ucontext(struct ib_ucontext *context); int bnxt_re_mmap(struct ib_ucontext *context, struct vm_area_struct *vma); void bnxt_re_mmap_free(struct rdma_user_mmap_entry *rdma_entry); +static inline u32 __to_ib_port_num(u16 port_id) +{ + return (u32)port_id + 1; +} unsigned long bnxt_re_lock_cqs(struct bnxt_re_qp *qp); void bnxt_re_unlock_cqs(struct bnxt_re_qp *qp, unsigned long flags); diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c b/drivers/infiniband/hw/bnxt_re/qplib_fp.c index b624c255eee6..00df8360dcd8 100644 --- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c +++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c @@ -1451,6 +1451,7 @@ int bnxt_qplib_query_qp(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp) qp->dest_qpn = le32_to_cpu(sb->dest_qp_id); memcpy(qp->smac, sb->src_mac, 6); qp->vlan_id = le16_to_cpu(sb->vlan_pcp_vlan_dei_vlan_id); + qp->port_id = le16_to_cpu(sb->port_id); bail: dma_free_coherent(&rcfw->pdev->dev, sbuf.size, sbuf.sb, sbuf.dma_addr); diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.h b/drivers/infiniband/hw/bnxt_re/qplib_fp.h index 5d4c49089a20..0e0df5083ed3 100644 --- a/drivers/infiniband/hw/bnxt_re/qplib_fp.h +++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.h @@ -297,6 +297,7 @@ struct bnxt_qplib_qp { u32 dest_qpn; u8 smac[6]; u16 vlan_id; + u16 port_id; u8 nw_type; struct bnxt_qplib_ah ah; -- 2.39.5

2 days, 12 hours

1
1
0 0

[PATCH AUTOSEL 6.12 1/8] selftests/sched_ext: fix build after renames in sched_ext API

by Sasha Levin

From: Ihor Solodrai <ihor.solodrai(a)pm.me> [ Upstream commit ef7009decc30eb2515a64253791d61b72229c119 ] The selftests are falining to build on current tip of bpf-next and sched_ext [1]. This has broken BPF CI [2] after merge from upstream. Use appropriate function names in the selftests according to the recent changes in the sched_ext API [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id… [2] https://github.com/kernel-patches/bpf/actions/runs/11959327258/job/33340923… [3] https://lore.kernel.org/all/20241109194853.580310-1-tj@kernel.org/ Signed-off-by: Ihor Solodrai <ihor.solodrai(a)pm.me> Acked-by: Andrea Righi <arighi(a)nvidia.com> Acked-by: David Vernet <void(a)manifault.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- .../testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c | 2 +- .../selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c | 4 ++-- tools/testing/selftests/sched_ext/dsp_local_on.bpf.c | 2 +- .../selftests/sched_ext/enq_select_cpu_fails.bpf.c | 2 +- tools/testing/selftests/sched_ext/exit.bpf.c | 4 ++-- tools/testing/selftests/sched_ext/maximal.bpf.c | 4 ++-- tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c | 2 +- .../selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c | 2 +- .../testing/selftests/sched_ext/select_cpu_dispatch.bpf.c | 2 +- .../selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c | 2 +- .../selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c | 4 ++-- tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c | 8 ++++---- 12 files changed, 19 insertions(+), 19 deletions(-) diff --git a/tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c b/tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c index 37d9bf6fb745..6f4c3f5a1c5d 100644 --- a/tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c +++ b/tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c @@ -20,7 +20,7 @@ s32 BPF_STRUCT_OPS(ddsp_bogus_dsq_fail_select_cpu, struct task_struct *p, * If we dispatch to a bogus DSQ that will fall back to the * builtin global DSQ, we fail gracefully. */ - scx_bpf_dispatch_vtime(p, 0xcafef00d, SCX_SLICE_DFL, + scx_bpf_dsq_insert_vtime(p, 0xcafef00d, SCX_SLICE_DFL, p->scx.dsq_vtime, 0); return cpu; } diff --git a/tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c b/tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c index dffc97d9cdf1..e4a55027778f 100644 --- a/tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c +++ b/tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c @@ -17,8 +17,8 @@ s32 BPF_STRUCT_OPS(ddsp_vtimelocal_fail_select_cpu, struct task_struct *p, if (cpu >= 0) { /* Shouldn't be allowed to vtime dispatch to a builtin DSQ. */ - scx_bpf_dispatch_vtime(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL, - p->scx.dsq_vtime, 0); + scx_bpf_dsq_insert_vtime(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL, + p->scx.dsq_vtime, 0); return cpu; } diff --git a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c index 6a7db1502c29..6325bf76f47e 100644 --- a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c +++ b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c @@ -45,7 +45,7 @@ void BPF_STRUCT_OPS(dsp_local_on_dispatch, s32 cpu, struct task_struct *prev) target = bpf_get_prandom_u32() % nr_cpus; - scx_bpf_dispatch(p, SCX_DSQ_LOCAL_ON | target, SCX_SLICE_DFL, 0); + scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL_ON | target, SCX_SLICE_DFL, 0); bpf_task_release(p); } diff --git a/tools/testing/selftests/sched_ext/enq_select_cpu_fails.bpf.c b/tools/testing/selftests/sched_ext/enq_select_cpu_fails.bpf.c index 1efb50d61040..a7cf868d5e31 100644 --- a/tools/testing/selftests/sched_ext/enq_select_cpu_fails.bpf.c +++ b/tools/testing/selftests/sched_ext/enq_select_cpu_fails.bpf.c @@ -31,7 +31,7 @@ void BPF_STRUCT_OPS(enq_select_cpu_fails_enqueue, struct task_struct *p, /* Can only call from ops.select_cpu() */ scx_bpf_select_cpu_dfl(p, 0, 0, &found); - scx_bpf_dispatch(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); + scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); } SEC(".struct_ops.link") diff --git a/tools/testing/selftests/sched_ext/exit.bpf.c b/tools/testing/selftests/sched_ext/exit.bpf.c index d75d4faf07f6..4bc36182d3ff 100644 --- a/tools/testing/selftests/sched_ext/exit.bpf.c +++ b/tools/testing/selftests/sched_ext/exit.bpf.c @@ -33,7 +33,7 @@ void BPF_STRUCT_OPS(exit_enqueue, struct task_struct *p, u64 enq_flags) if (exit_point == EXIT_ENQUEUE) EXIT_CLEANLY(); - scx_bpf_dispatch(p, DSQ_ID, SCX_SLICE_DFL, enq_flags); + scx_bpf_dsq_insert(p, DSQ_ID, SCX_SLICE_DFL, enq_flags); } void BPF_STRUCT_OPS(exit_dispatch, s32 cpu, struct task_struct *p) @@ -41,7 +41,7 @@ void BPF_STRUCT_OPS(exit_dispatch, s32 cpu, struct task_struct *p) if (exit_point == EXIT_DISPATCH) EXIT_CLEANLY(); - scx_bpf_consume(DSQ_ID); + scx_bpf_dsq_move_to_local(DSQ_ID); } void BPF_STRUCT_OPS(exit_enable, struct task_struct *p) diff --git a/tools/testing/selftests/sched_ext/maximal.bpf.c b/tools/testing/selftests/sched_ext/maximal.bpf.c index 4d4cd8d966db..4c005fa71810 100644 --- a/tools/testing/selftests/sched_ext/maximal.bpf.c +++ b/tools/testing/selftests/sched_ext/maximal.bpf.c @@ -20,7 +20,7 @@ s32 BPF_STRUCT_OPS(maximal_select_cpu, struct task_struct *p, s32 prev_cpu, void BPF_STRUCT_OPS(maximal_enqueue, struct task_struct *p, u64 enq_flags) { - scx_bpf_dispatch(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); + scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); } void BPF_STRUCT_OPS(maximal_dequeue, struct task_struct *p, u64 deq_flags) @@ -28,7 +28,7 @@ void BPF_STRUCT_OPS(maximal_dequeue, struct task_struct *p, u64 deq_flags) void BPF_STRUCT_OPS(maximal_dispatch, s32 cpu, struct task_struct *prev) { - scx_bpf_consume(SCX_DSQ_GLOBAL); + scx_bpf_dsq_move_to_local(SCX_DSQ_GLOBAL); } void BPF_STRUCT_OPS(maximal_runnable, struct task_struct *p, u64 enq_flags) diff --git a/tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c index f171ac470970..13d0f5be788d 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c @@ -30,7 +30,7 @@ void BPF_STRUCT_OPS(select_cpu_dfl_enqueue, struct task_struct *p, } scx_bpf_put_idle_cpumask(idle_mask); - scx_bpf_dispatch(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); + scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags); } SEC(".struct_ops.link") diff --git a/tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c index 9efdbb7da928..815f1d5d61ac 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c @@ -67,7 +67,7 @@ void BPF_STRUCT_OPS(select_cpu_dfl_nodispatch_enqueue, struct task_struct *p, saw_local = true; } - scx_bpf_dispatch(p, dsq_id, SCX_SLICE_DFL, enq_flags); + scx_bpf_dsq_insert(p, dsq_id, SCX_SLICE_DFL, enq_flags); } s32 BPF_STRUCT_OPS(select_cpu_dfl_nodispatch_init_task, diff --git a/tools/testing/selftests/sched_ext/select_cpu_dispatch.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_dispatch.bpf.c index 59bfc4f36167..4bb99699e920 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_dispatch.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_dispatch.bpf.c @@ -29,7 +29,7 @@ s32 BPF_STRUCT_OPS(select_cpu_dispatch_select_cpu, struct task_struct *p, cpu = prev_cpu; dispatch: - scx_bpf_dispatch(p, dsq_id, SCX_SLICE_DFL, 0); + scx_bpf_dsq_insert(p, dsq_id, SCX_SLICE_DFL, 0); return cpu; } diff --git a/tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c index 3bbd5fcdfb18..2a75de11b2cf 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c @@ -18,7 +18,7 @@ s32 BPF_STRUCT_OPS(select_cpu_dispatch_bad_dsq_select_cpu, struct task_struct *p s32 prev_cpu, u64 wake_flags) { /* Dispatching to a random DSQ should fail. */ - scx_bpf_dispatch(p, 0xcafef00d, SCX_SLICE_DFL, 0); + scx_bpf_dsq_insert(p, 0xcafef00d, SCX_SLICE_DFL, 0); return prev_cpu; } diff --git a/tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c index 0fda57fe0ecf..99d075695c97 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c @@ -18,8 +18,8 @@ s32 BPF_STRUCT_OPS(select_cpu_dispatch_dbl_dsp_select_cpu, struct task_struct *p s32 prev_cpu, u64 wake_flags) { /* Dispatching twice in a row is disallowed. */ - scx_bpf_dispatch(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, 0); - scx_bpf_dispatch(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, 0); + scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, 0); + scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, 0); return prev_cpu; } diff --git a/tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c b/tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c index e6c67bcf5e6e..bfcb96cd4954 100644 --- a/tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c +++ b/tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c @@ -2,8 +2,8 @@ /* * A scheduler that validates that enqueue flags are properly stored and * applied at dispatch time when a task is directly dispatched from - * ops.select_cpu(). We validate this by using scx_bpf_dispatch_vtime(), and - * making the test a very basic vtime scheduler. + * ops.select_cpu(). We validate this by using scx_bpf_dsq_insert_vtime(), + * and making the test a very basic vtime scheduler. * * Copyright (c) 2024 Meta Platforms, Inc. and affiliates. * Copyright (c) 2024 David Vernet <dvernet(a)meta.com> @@ -47,13 +47,13 @@ s32 BPF_STRUCT_OPS(select_cpu_vtime_select_cpu, struct task_struct *p, cpu = prev_cpu; scx_bpf_test_and_clear_cpu_idle(cpu); ddsp: - scx_bpf_dispatch_vtime(p, VTIME_DSQ, SCX_SLICE_DFL, task_vtime(p), 0); + scx_bpf_dsq_insert_vtime(p, VTIME_DSQ, SCX_SLICE_DFL, task_vtime(p), 0); return cpu; } void BPF_STRUCT_OPS(select_cpu_vtime_dispatch, s32 cpu, struct task_struct *p) { - if (scx_bpf_consume(VTIME_DSQ)) + if (scx_bpf_dsq_move_to_local(VTIME_DSQ)) consumed = true; } -- 2.39.5

2 days, 12 hours

1
7
0 0

[PATCH resubmit v2] spi: atmel-qspi: Memory barriers after memory-mapped I/O

by Bence Csókás

The QSPI peripheral control and status registers are accessible via the SoC's APB bus, whereas MMIO transactions' data travels on the AHB bus. Microchip documentation and even sample code from Atmel emphasises the need for a memory barrier before the first MMIO transaction to the AHB-connected QSPI, and before the last write to its registers via APB. This is achieved by the following lines in `atmel_qspi_transfer()`: /* Dummy read of QSPI_IFR to synchronize APB and AHB accesses */ (void)atmel_qspi_read(aq, QSPI_IFR); However, the current documentation makes no mention to synchronization requirements in the other direction, i.e. after the last data written via AHB, and before the first register access on APB. In our case, we were facing an issue where the QSPI peripheral would cease to send any new CSR (nCS Rise) interrupts, leading to a timeout in `atmel_qspi_wait_for_completion()` and ultimately this panic in higher levels: ubi0 error: ubi_io_write: error -110 while writing 63108 bytes to PEB 491:128, written 63104 bytes After months of extensive research of the codebase, fiddling around the debugger with kgdb, and back-and-forth with Microchip, we came to the conclusion that the issue is probably that the peripheral is still busy receiving on AHB when the LASTXFER bit is written to its Control Register on APB, therefore this write gets lost, and the peripheral still thinks there is more data to come in the MMIO transfer. This was first formulated when we noticed that doubling the write() of QSPI_CR_LASTXFER seemed to solve the problem. Ultimately, the solution is to introduce memory barriers after the AHB-mapped MMIO transfers, to ensure ordering. Fixes: d5433def3153 ("mtd: spi-nor: atmel-quadspi: Add spi-mem support to atmel-quadspi") Cc: Hari.PrasathGE(a)microchip.com Cc: Mahesh.Abotula(a)microchip.com Cc: Marco.Cardellini(a)microchip.com Cc: <stable(a)vger.kernel.org> # c0a0203cf579: ("spi: atmel-quadspi: Create `atmel_qspi_ops`"...) Cc: <stable(a)vger.kernel.org> # 6.x.y Signed-off-by: Bence Csókás <csokas.bence(a)prolan.hu> --- Notes: Changes in v2: * dropping --- from commit msg Resubmit: rebased on current spi-next drivers/spi/atmel-quadspi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c index f46da363574f..8fdc9d27a95e 100644 --- a/drivers/spi/atmel-quadspi.c +++ b/drivers/spi/atmel-quadspi.c @@ -661,13 +661,20 @@ static int atmel_qspi_transfer(struct spi_mem *mem, (void)atmel_qspi_read(aq, QSPI_IFR); /* Send/Receive data */ - if (op->data.dir == SPI_MEM_DATA_IN) + if (op->data.dir == SPI_MEM_DATA_IN) { memcpy_fromio(op->data.buf.in, aq->mem + offset, op->data.nbytes); - else + + /* Synchronize AHB and APB accesses again */ + rmb(); + } else { memcpy_toio(aq->mem + offset, op->data.buf.out, op->data.nbytes); + /* Synchronize AHB and APB accesses again */ + wmb(); + } + /* Release the chip-select */ atmel_qspi_write(QSPI_CR_LASTXFER, aq, QSPI_CR); -- 2.34.1

2 days, 13 hours

1
0
0 0

[PATCH] arm64: dts: exynos: gs101: disable pinctrl_gsacore node

by Peter Griffin

gsacore registers are not accessible from normal world. Disable this node, so that the suspend/resume callbacks in the pinctrl driver don't cause a Serror attempting to access the registers. Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> To: Rob Herring <robh(a)kernel.org> To: Krzysztof Kozlowski <krzk+dt(a)kernel.org> To: Conor Dooley <conor+dt(a)kernel.org> To: Alim Akhtar <alim.akhtar(a)samsung.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: devicetree(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: tudor.ambarus(a)linaro.org Cc: andre.draszik(a)linaro.org Cc: kernel-team(a)android.com Cc: willmcvicker(a)google.com Cc: stable(a)vger.kernel.org --- arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi index 302c5beb224a..b8f8255f840b 100644 --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi @@ -1451,6 +1451,7 @@ pinctrl_gsacore: pinctrl@17a80000 { /* TODO: update once support for this CMU exists */ clocks = <0>; clock-names = "pclk"; + status = "disabled"; }; cmu_top: clock-controller@1e080000 { --- base-commit: ed9a4ad6e5bd3a443e81446476718abebee47e82 change-id: 20241213-contrib-pg-pinctrl_gsacore_disable-3457c942b0fe Best regards, -- Peter Griffin <peter.griffin(a)linaro.org>

2 days, 13 hours

1
0
0 0

[PATCH 0/5] clk: Fix simple video pipelines on i.MX8

by Miquel Raynal

Recent changes in the clock tree have set CLK_SET_RATE_PARENT to the two LCDIF pixel clocks. The idea is, instead of using assigned-clock properties to set upstream PLL rates to high frequencies and hoping that a single divisor (namely media_disp[12]_pix) will be close enough in most cases, we should tell the clock core to use the PLL to properly derive an accurate pixel clock rate in the first place. Here is the situation. [Before ff06ea04e4cf ("clk: imx: clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")] Before setting CLK_SET_RATE_PARENT to the media_disp[12]_pix clocks, the sequence of events was: - PLL is assigned to a high rate, - media_disp[12]_pix is set to approximately freq A by using a single divisor, - media_ldb is set to approximately freq 7*A by using another single divisor. => The display was working, but the pixel clock was inaccurate. [After ff06ea04e4cf ("clk: imx: clk-imx8mp: Allow media_disp pixel clock reconfigure parent rate")] After setting CLK_SET_RATE_PARENT to the media_disp[12]_pix clocks, the sequence of events became: - media_disp[12]_pix is set to freq A by using a divisor of 1 and setting video_pll1 to freq A. - media_ldb is trying to compute its divisor to set freq 7*A, but the upstream PLL is to low, it does not recompute it, so it ends up setting a divisor of 1 and being at freq A instead of 7*A. => The display is sadly no longer working [After applying PATCH "clk: imx: clk-imx8mp: Allow LDB serializer clock reconfigure parent rate"] This is a commit from Marek, which is, I believe going in the right direction, so I am including it. Just with this change, the situation is slightly different, but the result is the same: - media_disp[12]_pix is set to freq A by using a divisor of 1 and setting video_pll1 to freq A. - media_ldb is set to 7*A by using a divisor of 1 and setting video_pll1 to freq 7*A. /!\ This as the side effect of changing media_disp[12]_pix from freq A to freq 7*A. => The display is still not working [After applying this series] The goal of the following patches is to prevent clock subtree walks to "just recalculate" the pixel clocks, ignoring the fact that they should no longer change. They should adapt their divisors to the new upstream rates instead. As a result, the display pipeline is working again. Note: if more than one display is connected, we need the LDB driver to act accordingly, thus the LDB driver must be adapted. Also, if accurate pixel clocks are not possible with two different displays, we will still need (at least for now) to make sure one of them is reparented to another PLL, like the audio PLL (but audio PLL are of a different kind, and are slightly less accurate). So this series aims at fixing the i.MX8MP display pipeline for simple setups. Said otherwise, returning to the same level of support as before, but with (hopefully) more accurate frequencies. I believe this approach manages to fix both Marek situation and all people using a straightforward LCD based setup. For more complex setups, we need more smartness from DRM and clk, but this is gonna take a bit of time. --- Marek Vasut (1): clk: imx: clk-imx8mp: Allow LDB serializer clock reconfigure parent rate Miquel Raynal (4): clk: Add a helper to determine a clock rate clk: Split clk_calc_subtree() clk: Add flag to prevent frequency changes when walking subtrees clk: imx: imx8mp: Prevent media clocks to be incompatibly changed drivers/clk/clk.c | 39 ++++++++++++++++++++++++++++++++------- drivers/clk/imx/clk-imx8mp.c | 6 +++--- include/linux/clk-provider.h | 2 ++ 3 files changed, 37 insertions(+), 10 deletions(-) --- base-commit: 62facaf164585923d081eedcb6871f4ff3c2e953 change-id: 20241121-ge-ian-debug-imx8-clk-tree-bd325aa866f1 Best regards, -- Miquel Raynal <miquel.raynal(a)bootlin.com>

2 days, 14 hours

3
9
0 0

Re: Patch "watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for PMU regs" has been added to the 6.6-stable tree

by Peter Griffin

Hi Sasha, + cc stable(a)vger.kernel.org On Fri, 3 Jan 2025 at 00:45, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for PMU regs > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > watchdog-s3c2410_wdt-use-exynos_get_pmu_regmap_by_ph.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. It doesn't make sense (to me at least) to add this patch and then also add the revert of it to v6.6 stable tree, as it becomes a no-op. The only reason I can think of is it somehow helps with your automated tooling? Additionally the hardware (Pixel 6 & gs101 SoC ) which these patches and APIs were added for wasn't merged until v6.8. The revert is also only applicable if the kernel has the corresponding enhancements made to syscon driver to register custom regmaps. See 769cb63166d9 ("mfd: syscon: Add of_syscon_register_regmap() API") Thanks, Peter

2 days, 14 hours

2
3
0 0

Re: Patch "vmstat: disable vmstat_work on vmstat_cpu_down_prep()" has been added to the 6.12-stable tree

by Koichiro Den

On Mon, Jan 06, 2025 at 11:41:20AM +0100, gregkh(a)linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > vmstat: disable vmstat_work on vmstat_cpu_down_prep() > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Hi, could you hold off on adding this for now? It's broken [1] and needs to be fixed. Once a follow-up fix is ready, I'll make sure to notify you. [1] https://lore.kernel.org/linux-mm/7ed97096-859e-46d0-8f27-16a2298a8914@lucif… Thanks. -Koichiro Den > > > From adcfb264c3ed51fbbf5068ddf10d309a63683868 Mon Sep 17 00:00:00 2001 > From: Koichiro Den <koichiro.den(a)canonical.com> > Date: Sat, 21 Dec 2024 12:33:20 +0900 > Subject: vmstat: disable vmstat_work on vmstat_cpu_down_prep() > > From: Koichiro Den <koichiro.den(a)canonical.com> > > commit adcfb264c3ed51fbbf5068ddf10d309a63683868 upstream. > > Even after mm/vmstat:online teardown, shepherd may still queue work for > the dying cpu until the cpu is removed from online mask. While it's quite > rare, this means that after unbind_workers() unbinds a per-cpu kworker, it > potentially runs vmstat_update for the dying CPU on an irrelevant cpu > before entering atomic AP states. When CONFIG_DEBUG_PREEMPT=y, it results > in the following error with the backtrace. > > BUG: using smp_processor_id() in preemptible [00000000] code: \ > kworker/7:3/1702 > caller is refresh_cpu_vm_stats+0x235/0x5f0 > CPU: 0 UID: 0 PID: 1702 Comm: kworker/7:3 Tainted: G > Tainted: [N]=TEST > Workqueue: mm_percpu_wq vmstat_update > Call Trace: > <TASK> > dump_stack_lvl+0x8d/0xb0 > check_preemption_disabled+0xce/0xe0 > refresh_cpu_vm_stats+0x235/0x5f0 > vmstat_update+0x17/0xa0 > process_one_work+0x869/0x1aa0 > worker_thread+0x5e5/0x1100 > kthread+0x29e/0x380 > ret_from_fork+0x2d/0x70 > ret_from_fork_asm+0x1a/0x30 > </TASK> > > So, for mm/vmstat:online, disable vmstat_work reliably on teardown and > symmetrically enable it on startup. > > Link: https://lkml.kernel.org/r/20241221033321.4154409-1-koichiro.den@canonical.c… > Signed-off-by: Koichiro Den <koichiro.den(a)canonical.com> > Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> > Cc: <stable(a)vger.kernel.org> > Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > mm/vmstat.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -2139,13 +2139,14 @@ static int vmstat_cpu_online(unsigned in > if (!node_state(cpu_to_node(cpu), N_CPU)) { > node_set_state(cpu_to_node(cpu), N_CPU); > } > + enable_delayed_work(&per_cpu(vmstat_work, cpu)); > > return 0; > } > > static int vmstat_cpu_down_prep(unsigned int cpu) > { > - cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > + disable_delayed_work_sync(&per_cpu(vmstat_work, cpu)); > return 0; > } > > > > Patches currently in stable-queue which might be from koichiro.den(a)canonical.com are > > queue-6.12/vmstat-disable-vmstat_work-on-vmstat_cpu_down_prep.patch

2 days, 15 hours

2
1
0 0

[PATCH] x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs

by Jann Horn

On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. Cc: stable(a)vger.kernel.org Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range") Signed-off-by: Jann Horn <jannh(a)google.com> --- arch/x86/include/asm/tlbflush.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index 02fc2aa06e9e0ecdba3fe948cafe5892b72e86c0..3da645139748538daac70166618d8ad95116eb74 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -242,7 +242,7 @@ void flush_tlb_multi(const struct cpumask *cpumask, flush_tlb_mm_range((vma)->vm_mm, start, end, \ ((vma)->vm_flags & VM_HUGETLB) \ ? huge_page_shift(hstate_vma(vma)) \ - : PAGE_SHIFT, false) + : PAGE_SHIFT, true) extern void flush_tlb_all(void); extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, --- base-commit: aa135d1d0902c49ed45bec98c61c1b4022652b7e change-id: 20250103-x86-collapse-flush-fix-fa87ac4d5834 -- Jann Horn <jannh(a)google.com>

2 days, 15 hours

2
4
0 0

[PATCHv3 1/2] media: venus: destroy hfi session after m2m_ctx release

by Sergey Senozhatsky

This partially reverts commit that made hfi_session_destroy() the first step of vdec/venc close(). The reason being is a regression report when, supposedly, encode/decoder is closed with still active streaming (no ->stop_streaming() call before close()) and pending pkts, so isr_thread cannot find instance and fails to process those pending pkts. This was the idea behind the original patch - make it impossible to use instance under destruction, because this is racy, but apparently there are uses cases that depend on that unsafe pattern. Return to the old (unsafe) behaviour for the time being (until a better fix is found). Fixes: 45b1a1b348ec1 ("media: venus: sync with threaded IRQ during inst destruction") Cc: stable(a)vger.kernel.org Reported-by: Nathan Hebert <nhebert(a)google.com> Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> --- drivers/media/platform/qcom/venus/core.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 2d27c5167246..807487a1f536 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -506,18 +506,14 @@ static __maybe_unused int venus_runtime_suspend(struct device *dev) void venus_close_common(struct venus_inst *inst) { /* - * First, remove the inst from the ->instances list, so that - * to_instance() will return NULL. - */ - hfi_session_destroy(inst); - /* - * Second, make sure we don't have IRQ/IRQ-thread currently running + * Make sure we don't have IRQ/IRQ-thread currently running * or pending execution, which would race with the inst destruction. */ synchronize_irq(inst->core->irq); v4l2_m2m_ctx_release(inst->m2m_ctx); v4l2_m2m_release(inst->m2m_dev); + hfi_session_destroy(inst); v4l2_fh_del(&inst->fh); v4l2_fh_exit(&inst->fh); v4l2_ctrl_handler_free(&inst->ctrl_handler); -- 2.47.1.613.gc27f4b7a9f-goog

2 days, 15 hours

2
2
0 0

[PATCH] ACPI: resource: Add Asus Vivobook X1504VAP to irq1_level_low_skip_override[]

by Gustavo Azor

Estimated people: Seems to me, I browse drivers/acpi/resources.c: the patch was not included in kernel versions stable 6.12.7 or long term 6.6.68. I hope will be include in mainline 6.13.-rc5 to inform if work in the ASUS Vivobook 15 X1504VAP_X1504VA keyboard. I have not idea how work with git diff or compiling kernels to try the patch, and need to try in installed kernel. Thanks.Regards. Sent: Friday, December 20, 2024 at 8:23 PM From: bugzilla-daemon(a)kernel.org To: gazo11(a)mail.com Subject: [Bug 219224] Laptop Internal Keyboard not working on ASUS VivoBook E1404GA on ubuntu 24.04. https://bugzilla.kernel.org/show_bug.cgi?id=219224 --- Comment #11 from Hans de Goede (jwrdegoede(a)fedoraproject.org) --- (In reply to gazo11 from comment #10) > Hello I have the same problem for dmidecode: > > > System Information > Manufacturer: ASUSTeK COMPUTER INC. > Product Name: ASUS Vivobook 15 X1504VAP_X1504VA > Version: 1.0 > Serial Number: S1N0CV02L86302G > UUID: cdc508f0-d3f1-f743-bce4-5eb9d4c06fda > Wake-up Type: Power Switch > SKU Number: > Family: ASUS Vivobook 15 > > Its possible to get this model listed in future kernels? Thanks! Thank you for reporting this, I've submitted a patch to add this to the irq1_level_low_skip_override[] list: https://lore.kernel.org/linux-acpi/20241220181352.25974-1-hdegoede@redhat.c… -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.

2 days, 16 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025