- Linux-stable-mirror - lists.linaro.org

[PATCH V3][5.15.y] bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq

by guocai.he.cn＠windriver.com

From: Michal Schmidt <mschmidt(a)redhat.com> commit 78cfd17142ef70599d6409cbd709d94b3da58659 upstream. Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis(a)abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]--- Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Signed-off-by: Michal Schmidt <mschmidt(a)redhat.com> Link: https://lore.kernel.org/r/20240507103929.30003-1-mschmidt@redhat.com Acked-by: Selvin Xavier <selvin.xavier(a)broadcom.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Guocai He <guocai.he.cn(a)windriver.com> --- This commit is to solve the CVE-2024-38540. Please merge this commit to linux-5.15.y. drivers/infiniband/hw/bnxt_re/qplib_fp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c b/drivers/infiniband/hw/bnxt_re/qplib_fp.c index dea70db9ee97..82d7381dbd6d 100644 --- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c +++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c @@ -1013,7 +1013,8 @@ int bnxt_qplib_create_qp(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp) hwq_attr.stride = sizeof(struct sq_sge); hwq_attr.depth = bnxt_qplib_get_depth(sq); hwq_attr.aux_stride = psn_sz; - hwq_attr.aux_depth = bnxt_qplib_set_sq_size(sq, qp->wqe_mode); + hwq_attr.aux_depth = psn_sz ? bnxt_qplib_set_sq_size(sq, qp->wqe_mode) + : 0; hwq_attr.type = HWQ_TYPE_QUEUE; rc = bnxt_qplib_alloc_init_hwq(&sq->hwq, &hwq_attr); if (rc) -- 2.34.1 V3: Cherry-pick not from 6.1.y but from upstream directly.

1 month, 3 weeks

3
3
0 0

[PATCH V2][5.15.y] gfs2: Fix slab-use-after-free in gfs2_qd_dealloc

by guocai.he.cn＠windriver.com

From: Juntong Deng <juntong.deng(a)outlook.com> commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 upstream. In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again. Reported-by: syzbot+29c47e9e51895928698c(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=29c47e9e51895928698c Signed-off-by: Juntong Deng <juntong.deng(a)outlook.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Guocai He <guocai.he.cn(a)windriver.com> --- Changes in v2: Correct the upstream commit id. This commit is to solve the CVE-2024-52760. Please merge this commit to linux-5.15.y. --- fs/gfs2/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c index 268651ac9fc8..98158559893f 100644 --- a/fs/gfs2/super.c +++ b/fs/gfs2/super.c @@ -590,6 +590,8 @@ static void gfs2_put_super(struct super_block *sb) if (!sb_rdonly(sb)) { gfs2_make_fs_ro(sdp); + } else { + gfs2_quota_cleanup(sdp); } WARN_ON(gfs2_withdrawing(sdp)); -- 2.34.1

1 month, 3 weeks

2
1
0 0

[PATCH 6.6] rtla/timerlat: Make timerlat_hist_cpu->*_count unsigned long long

by tglozar＠redhat.com

From: Tomas Glozar <tglozar(a)redhat.com> commit 76b3102148135945b013797fac9b206273f0f777 upstream. Do the same fix as in previous commit also for timerlat-hist. Link: https://lore.kernel.org/20241011121015.2868751-2-tglozar@redhat.com Reported-by: Attila Fazekas <afazekas(a)redhat.com> Signed-off-by: Tomas Glozar <tglozar(a)redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [ Drop hunk fixing printf in timerlat_print_stats_all since that is not in 6.6 ] Signed-off-by: Tomas Glozar <tglozar(a)redhat.com> --- tools/tracing/rtla/src/timerlat_hist.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/tracing/rtla/src/timerlat_hist.c b/tools/tracing/rtla/src/timerlat_hist.c index 1c8ecd4ebcbd..667f12f2d67f 100644 --- a/tools/tracing/rtla/src/timerlat_hist.c +++ b/tools/tracing/rtla/src/timerlat_hist.c @@ -58,9 +58,9 @@ struct timerlat_hist_cpu { int *thread; int *user; - int irq_count; - int thread_count; - int user_count; + unsigned long long irq_count; + unsigned long long thread_count; + unsigned long long user_count; unsigned long long min_irq; unsigned long long sum_irq; @@ -300,15 +300,15 @@ timerlat_print_summary(struct timerlat_hist_params *params, continue; if (!params->no_irq) - trace_seq_printf(trace->seq, "%9d ", + trace_seq_printf(trace->seq, "%9llu ", data->hist[cpu].irq_count); if (!params->no_thread) - trace_seq_printf(trace->seq, "%9d ", + trace_seq_printf(trace->seq, "%9llu ", data->hist[cpu].thread_count); if (params->user_hist) - trace_seq_printf(trace->seq, "%9d ", + trace_seq_printf(trace->seq, "%9llu ", data->hist[cpu].user_count); } trace_seq_printf(trace->seq, "\n"); -- 2.47.1

1 month, 3 weeks

2
1
0 0

[PATCH 5.15.y 5.10.y] virtio/vsock: Fix accept_queue memory leak

by Tomas Krcka

From: Michal Luczaj <mhal(a)rbox.co> [ Upstream commit d7b0ff5a866724c3ad21f2628c22a63336deec3f ] As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 Fixes: 3fe356d58efa ("vsock/virtio: discard packets only when socket is really closed") Reviewed-by: Stefano Garzarella <sgarzare(a)redhat.com> Signed-off-by: Michal Luczaj <mhal(a)rbox.co> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Adapted due to missing commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")] Signed-off-by: Tomas Krcka <krckatom(a)amazon.de> --- net/vmw_vsock/virtio_transport_common.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c index b626c7e8e61a..ccbee1723b07 100644 --- a/net/vmw_vsock/virtio_transport_common.c +++ b/net/vmw_vsock/virtio_transport_common.c @@ -1062,6 +1062,14 @@ virtio_transport_recv_listen(struct sock *sk, struct virtio_vsock_pkt *pkt, return -ENOMEM; } + /* __vsock_release() might have already flushed accept_queue. + * Subsequent enqueues would lead to a memory leak. + */ + if (sk->sk_shutdown == SHUTDOWN_MASK) { + virtio_transport_reset_no_sock(t, pkt); + return -ESHUTDOWN; + } + child = vsock_create_connected(sk); if (!child) { virtio_transport_reset_no_sock(t, pkt); -- 2.40.1

1 month, 3 weeks

2
1
0 0

[PATCH v2 00/19] arm64: dts: qcom: Fix remoteproc memory base and length

by Krzysztof Kozlowski

Changes in v2: - arm64: dts: qcom: x1e80100: Fix ADSP...: Commit msg corrections, second paragraph (Johan) - Add tags - Link to v1: https://lore.kernel.org/r/20241206-dts-qcom-cdsp-mpss-base-address-v1-0-2f3… Konrad pointed out during SM8750 review, that numbers are odd, so I looked at datasheets and downstream DTS for all previous platforms. Most numbers are odd. Older platforms like SM8150, SM8250, SC7280, SC8180X seem fine. I could not check few like SDX75 or SM6115, due to lack of access to datasheets. SM8350, SM8450, SM8550 tested on hardware. Others not, but I don't expect any failures because PAS drivers do not use the address space. Which also explains why odd numbers did not result in any failures. Best regards, Krzysztof --- Krzysztof Kozlowski (19): arm64: dts: qcom: sm8350: Fix ADSP memory base and length arm64: dts: qcom: sm8350: Fix CDSP memory base and length arm64: dts: qcom: sm8350: Fix MPSS memory length arm64: dts: qcom: sm8450: Fix ADSP memory base and length arm64: dts: qcom: sm8450: Fix CDSP memory length arm64: dts: qcom: sm8450: Fix MPSS memory length arm64: dts: qcom: sm8550: Fix ADSP memory base and length arm64: dts: qcom: sm8550: Fix CDSP memory length arm64: dts: qcom: sm8550: Fix MPSS memory length [RFT] arm64: dts: qcom: sm8650: Fix ADSP memory base and length [RFT] arm64: dts: qcom: sm8650: Fix CDSP memory length [RFT] arm64: dts: qcom: sm8650: Fix MPSS memory length arm64: dts: qcom: x1e80100: Fix ADSP memory base and length arm64: dts: qcom: x1e80100: Fix CDSP memory length arm64: dts: qcom: sm6350: Fix ADSP memory length arm64: dts: qcom: sm6350: Fix MPSS memory length [RFT] arm64: dts: qcom: sm6375: Fix ADSP memory length [RFT] arm64: dts: qcom: sm6375: Fix CDSP memory base and length [RFT] arm64: dts: qcom: sm6375: Fix MPSS memory base and length arch/arm64/boot/dts/qcom/sm6350.dtsi | 4 +- arch/arm64/boot/dts/qcom/sm6375.dtsi | 10 +- arch/arm64/boot/dts/qcom/sm8350.dtsi | 492 ++++++++++++++++----------------- arch/arm64/boot/dts/qcom/sm8450.dtsi | 216 +++++++-------- arch/arm64/boot/dts/qcom/sm8550.dtsi | 266 +++++++++--------- arch/arm64/boot/dts/qcom/sm8650.dtsi | 300 ++++++++++---------- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 276 +++++++++--------- 7 files changed, 782 insertions(+), 782 deletions(-) --- base-commit: c245a7a79602ccbee780c004c1e4abcda66aec32 change-id: 20241206-dts-qcom-cdsp-mpss-base-address-ae7c406ac9ac Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

1 month, 3 weeks

2
33
0 0

[PATCH v5 1/6] PCI: dwc: ep: iATU registers must be written after the BAR_MASK

by Niklas Cassel

The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested size of the first set_bar() call. The reset value of the BAR_MASK is SoC dependent. Thus, if the first set_bar() call requests a size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.0

1 month, 3 weeks

3
4
0 0

[PATCH v6 2/6] PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

by Niklas Cassel

In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) Cc: stable(a)vger.kernel.org Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index bad588ef69a4..44a617d54b15 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,8 +222,28 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - if (ep->epf_bar[bar]) + /* + * Certain EPF drivers dynamically change the physical address of a BAR + * (i.e. they call set_bar() twice, without ever calling clear_bar(), as + * calling clear_bar() would clear the BAR's PCI address assigned by the + * host). + */ + if (ep->epf_bar[bar]) { + /* + * We can only dynamically change a BAR if the new BAR size and + * BAR flags do not differ from the existing configuration. + */ + if (ep->epf_bar[bar]->barno != bar || + ep->epf_bar[bar]->size != size || + ep->epf_bar[bar]->flags != flags) + return -EINVAL; + + /* + * When dynamically changing a BAR, skip writing the BAR reg, as + * that would clear the BAR's PCI address assigned by the host. + */ goto config_atu; + } reg = PCI_BASE_ADDRESS_0 + (4 * bar); -- 2.47.1

1 month, 3 weeks

1
0
0 0

[PATCH v6 1/6] PCI: dwc: ep: Write BAR_MASK before iATU registers in pci_epc_set_bar()

by Niklas Cassel

The "DesignWare Cores PCI Express Controller Register Descriptions, Version 4.60a", section "1.21.70 IATU_LWR_TARGET_ADDR_OFF_INBOUND_i", fields LWR_TARGET_RW and LWR_TARGET_HW both state that: "Field size depends on log2(BAR_MASK+1) in BAR match mode." I.e. only the upper bits are writable, and the number of writable bits is dependent on the configured BAR_MASK. If we do not write the BAR_MASK before writing the iATU registers, we are relying the reset value of the BAR_MASK being larger than the requested BAR size (which is supplied in the struct pci_epf_bar which is passed to pci_epc_set_bar()). The reset value of the BAR_MASK is SoC dependent. Thus, if the struct pci_epf_bar requests a BAR size that is larger than the reset value of the BAR_MASK, the iATU will try to write to read-only bits, which will cause the iATU to end up redirecting to a physical address that is different from the address that was intended. Thus, we should always write the iATU registers after writing the BAR_MASK. Cc: stable(a)vger.kernel.org Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- .../pci/controller/dwc/pcie-designware-ep.c | 28 ++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c index f3ac7d46a855..bad588ef69a4 100644 --- a/drivers/pci/controller/dwc/pcie-designware-ep.c +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c @@ -222,19 +222,10 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, if ((flags & PCI_BASE_ADDRESS_MEM_TYPE_64) && (bar & 1)) return -EINVAL; - reg = PCI_BASE_ADDRESS_0 + (4 * bar); - - if (!(flags & PCI_BASE_ADDRESS_SPACE)) - type = PCIE_ATU_TYPE_MEM; - else - type = PCIE_ATU_TYPE_IO; - - ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); - if (ret) - return ret; - if (ep->epf_bar[bar]) - return 0; + goto config_atu; + + reg = PCI_BASE_ADDRESS_0 + (4 * bar); dw_pcie_dbi_ro_wr_en(pci); @@ -246,9 +237,20 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no, dw_pcie_ep_writel_dbi(ep, func_no, reg + 4, 0); } - ep->epf_bar[bar] = epf_bar; dw_pcie_dbi_ro_wr_dis(pci); +config_atu: + if (!(flags & PCI_BASE_ADDRESS_SPACE)) + type = PCIE_ATU_TYPE_MEM; + else + type = PCIE_ATU_TYPE_IO; + + ret = dw_pcie_ep_inbound_atu(ep, func_no, type, epf_bar->phys_addr, bar); + if (ret) + return ret; + + ep->epf_bar[bar] = epf_bar; + return 0; } -- 2.47.1

1 month, 3 weeks

1
0
0 0

[PATCH v2] soc: qcom: llcc: Enable LLCC_WRCACHE at boot on X1

by Konrad Dybcio

From: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Do so in accordance with the internal recommendations. Fixes: b3cf69a43502 ("soc: qcom: llcc: Add configuration data for X1E80100") Cc: stable(a)vger.kernel.org Reviewed-by: Rajendra Nayak <quic_rjendra(a)quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> --- Changes in v2: - Cc stable - Add more context lines - Pick up r-b - Link to v1: https://lore.kernel.org/r/20241207-topic-llcc_x1e_wrcache-v1-1-232e6aff49e4… --- drivers/soc/qcom/llcc-qcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c index 32c3bc887cefb87c296e3ba67a730c87fa2fa346..1560db00a01248197e5c2936e785a5ea77f74ad8 100644 --- a/drivers/soc/qcom/llcc-qcom.c +++ b/drivers/soc/qcom/llcc-qcom.c @@ -2997,20 +2997,21 @@ static const struct llcc_slice_config x1e80100_data[] = { .bonus_ways = 0xfff, .cache_mode = 0, }, { .usecase_id = LLCC_WRCACHE, .slice_id = 31, .max_cap = 1024, .priority = 1, .fixed_size = true, .bonus_ways = 0xfff, .cache_mode = 0, + .activate_on_init = true, }, { .usecase_id = LLCC_CAMEXP0, .slice_id = 4, .max_cap = 256, .priority = 4, .fixed_size = true, .bonus_ways = 0x3, .cache_mode = 0, }, { .usecase_id = LLCC_CAMEXP1, --- base-commit: 3e42dc9229c5950e84b1ed705f94ed75ed208228 change-id: 20241207-topic-llcc_x1e_wrcache-647070e2d130 Best regards, -- Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com>

1 month, 3 weeks

3
3
0 0

[PATCH v4 0/7] drm: Add DSI/DP support for Renesas r8a779h0 V4M and grey-hawk board

by Tomi Valkeinen

Add everything needed to support the DSI output on Renesas r8a779h0 (V4M) SoC, and the DP output (via sn65dsi86 DSI to DP bridge) on the Renesas grey-hawk board. Overall the DSI and the board design is almost identical to Renesas r8a779g0 and white-hawk board. Note: the v4 no longer has the dts and the clk patches, as those have been merged to renesas-devel. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas(a)ideasonboard.com> --- Changes in v4: - Dropped patches merged to renesas-devel - Added new patch "dt-bindings: display: renesas,du: Add missing maxItems" to fix the bindings - Add the missing maxItems to "dt-bindings: display: renesas,du: Add r8a779h0" - Link to v3: https://lore.kernel.org/r/20241206-rcar-gh-dsi-v3-0-d74c2166fa15@ideasonboa… Changes in v3: - Update "Write DPTSR only if there are more than one crtc" patch to "Write DPTSR only if the second source exists" - Add Laurent's Rb - Link to v2: https://lore.kernel.org/r/20241205-rcar-gh-dsi-v2-0-42471851df86@ideasonboa… Changes in v2: - Add the DT binding with a new conditional block, so that we can set only the port@0 as required - Drop port@1 from r8a779h0.dtsi (there's no port@1) - Add a new patch to write DPTSR only if num_crtcs > 1 - Drop RCAR_DU_FEATURE_NO_DPTSR (not needed anymore) - Add Cc: stable to the fix, and move it as first patch - Added the tags from reviews - Link to v1: https://lore.kernel.org/r/20241203-rcar-gh-dsi-v1-0-738ae1a95d2a@ideasonboa… --- Tomi Valkeinen (7): drm/rcar-du: dsi: Fix PHY lock bit check drm/rcar-du: Write DPTSR only if the second source exists dt-bindings: display: renesas,du: Add missing maxItems dt-bindings: display: renesas,du: Add r8a779h0 dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779h0 drm/rcar-du: dsi: Add r8a779h0 support drm/rcar-du: Add support for r8a779h0 .../display/bridge/renesas,dsi-csi2-tx.yaml | 1 + .../devicetree/bindings/display/renesas,du.yaml | 63 ++++++++++++++++++++-- drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 18 +++++++ drivers/gpu/drm/renesas/rcar-du/rcar_du_group.c | 24 ++++++--- drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 4 +- .../gpu/drm/renesas/rcar-du/rcar_mipi_dsi_regs.h | 1 - 6 files changed, 99 insertions(+), 12 deletions(-) --- base-commit: adc218676eef25575469234709c2d87185ca223a change-id: 20241008-rcar-gh-dsi-9c01f5deeac8 Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

1 month, 3 weeks

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror