Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

20 participants
123736 discussions

[PATCH] vfio/pci: Disable qword access to the PCI ROM bar

by Kevin Tian

Commit 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") enables qword access to the PCI bar resources. However certain devices (e.g. Intel X710) are observed with problem upon qword accesses to the rom bar, e.g. triggering PCI aer errors. Instead of trying to identify all broken devices, universally disable qword access to the rom bar i.e. going back to the old way which worked reliably for years. Reported-by: Farrah Chen <farrah.chen(a)intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220740 Fixes: 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci") Cc: stable(a)vger.kernel.org Signed-off-by: Kevin Tian <kevin.tian(a)intel.com> --- drivers/vfio/pci/nvgrace-gpu/main.c | 4 ++-- drivers/vfio/pci/vfio_pci_rdwr.c | 19 +++++++++++++++---- include/linux/vfio_pci_core.h | 2 +- 3 files changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c index e346392b72f6..9b39184f76b7 100644 --- a/drivers/vfio/pci/nvgrace-gpu/main.c +++ b/drivers/vfio/pci/nvgrace-gpu/main.c @@ -491,7 +491,7 @@ nvgrace_gpu_map_and_read(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, buf, offset, mem_count, - 0, 0, false); + 0, 0, false, true); } return ret; @@ -609,7 +609,7 @@ nvgrace_gpu_map_and_write(struct nvgrace_gpu_pci_core_device *nvdev, ret = vfio_pci_core_do_io_rw(&nvdev->core_device, false, nvdev->resmem.ioaddr, (char __user *)buf, pos, mem_count, - 0, 0, true); + 0, 0, true, true); } return ret; diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c index 6192788c8ba3..95dc7e04cb08 100644 --- a/drivers/vfio/pci/vfio_pci_rdwr.c +++ b/drivers/vfio/pci/vfio_pci_rdwr.c @@ -135,7 +135,7 @@ VFIO_IORDWR(64) ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite) + size_t x_end, bool iswrite, bool allow_qword) { ssize_t done = 0; int ret; @@ -150,7 +150,7 @@ ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, else fillable = 0; - if (fillable >= 8 && !(off % 8)) { + if (allow_qword && fillable >= 8 && !(off % 8)) { ret = vfio_pci_iordwr64(vdev, iswrite, test_mem, io, buf, off, &filled); if (ret) @@ -234,6 +234,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, void __iomem *io; struct resource *res = &vdev->pdev->resource[bar]; ssize_t done; + bool allow_qword = true; if (pci_resource_start(pdev, bar)) end = pci_resource_len(pdev, bar); @@ -262,6 +263,16 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, if (!io) return -ENOMEM; x_end = end; + + /* + * Certain devices (e.g. Intel X710) don't support qword + * access to the ROM bar. Otherwise PCI AER errors might be + * triggered. + * + * Disable qword access to the ROM bar universally, which + * worked reliably for years before qword access is enabled. + */ + allow_qword = false; } else { int ret = vfio_pci_core_setup_barmap(vdev, bar); if (ret) { @@ -278,7 +289,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_core_device *vdev, char __user *buf, } done = vfio_pci_core_do_io_rw(vdev, res->flags & IORESOURCE_MEM, io, buf, pos, - count, x_start, x_end, iswrite); + count, x_start, x_end, iswrite, allow_qword); if (done >= 0) *ppos += done; @@ -352,7 +363,7 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_core_device *vdev, char __user *buf, * to the memory enable bit in the command register. */ done = vfio_pci_core_do_io_rw(vdev, false, iomem, buf, off, count, - 0, 0, iswrite); + 0, 0, iswrite, true); vga_put(vdev->pdev, rsrc); diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h index f541044e42a2..3a75b76eaed3 100644 --- a/include/linux/vfio_pci_core.h +++ b/include/linux/vfio_pci_core.h @@ -133,7 +133,7 @@ pci_ers_result_t vfio_pci_core_aer_err_detected(struct pci_dev *pdev, ssize_t vfio_pci_core_do_io_rw(struct vfio_pci_core_device *vdev, bool test_mem, void __iomem *io, char __user *buf, loff_t off, size_t count, size_t x_start, - size_t x_end, bool iswrite); + size_t x_end, bool iswrite, bool allow_qword); bool vfio_pci_core_range_intersect_range(loff_t buf_start, size_t buf_cnt, loff_t reg_start, size_t reg_cnt, loff_t *buf_offset, -- 2.43.0

2 weeks, 1 day

[PATCH] PCI: meson: Remove meson_pcie_link_up() timeout, message, speed check

by Bjorn Helgaas

From: Bjorn Helgaas <bhelgaas(a)google.com> Previously meson_pcie_link_up() only returned true if the link was in the L0 state. This was incorrect because hardware autonomously manages transitions between L0, L0s, and L1 while both components on the link stay in D0. Those states should all be treated as "link is active". Returning false when the device was in L0s or L1 broke config accesses because dw_pcie_other_conf_map_bus() fails if the link is down, which caused errors like this: meson-pcie fc000000.pcie: error: wait linkup timeout pci 0000:01:00.0: BAR 0: error updating (0xfc700004 != 0xffffffff) Remove the LTSSM state check, timeout, speed check, and error message from meson_pcie_link_up(), the dw_pcie_ops.link_up() method, so it is a simple boolean check of whether the link is active. Timeouts and and error messages are handled at a higher level, e.g., dw_pcie_wait_for_link(). Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Reported-by: Linnaea Lavia <linnaea-von-lavia(a)live.com> Closes: https://lore.kernel.org/r/DM4PR05MB102707B8CDF84D776C39F22F2C7F0A@DM4PR05MB… Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Linnaea Lavia <linnaea-von-lavia(a)live.com> Cc: stable(a)vger.kernel.org --- drivers/pci/controller/dwc/pci-meson.c | 36 +++----------------------- 1 file changed, 3 insertions(+), 33 deletions(-) diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c index 787469d1b396..13685d89227a 100644 --- a/drivers/pci/controller/dwc/pci-meson.c +++ b/drivers/pci/controller/dwc/pci-meson.c @@ -338,40 +338,10 @@ static struct pci_ops meson_pci_ops = { static bool meson_pcie_link_up(struct dw_pcie *pci) { struct meson_pcie *mp = to_meson_pcie(pci); - struct device *dev = pci->dev; - u32 speed_okay = 0; - u32 cnt = 0; - u32 state12, state17, smlh_up, ltssm_up, rdlh_up; + u32 state12; - do { - state12 = meson_cfg_readl(mp, PCIE_CFG_STATUS12); - state17 = meson_cfg_readl(mp, PCIE_CFG_STATUS17); - smlh_up = IS_SMLH_LINK_UP(state12); - rdlh_up = IS_RDLH_LINK_UP(state12); - ltssm_up = IS_LTSSM_UP(state12); - - if (PM_CURRENT_STATE(state17) < PCIE_GEN3) - speed_okay = 1; - - if (smlh_up) - dev_dbg(dev, "smlh_link_up is on\n"); - if (rdlh_up) - dev_dbg(dev, "rdlh_link_up is on\n"); - if (ltssm_up) - dev_dbg(dev, "ltssm_up is on\n"); - if (speed_okay) - dev_dbg(dev, "speed_okay\n"); - - if (smlh_up && rdlh_up && ltssm_up && speed_okay) - return true; - - cnt++; - - udelay(10); - } while (cnt < WAIT_LINKUP_TIMEOUT); - - dev_err(dev, "error: wait linkup timeout\n"); - return false; + state12 = meson_cfg_readl(mp, PCIE_CFG_STATUS12); + return IS_SMLH_LINK_UP(state12) && IS_RDLH_LINK_UP(state12); } static int meson_pcie_host_init(struct dw_pcie_rp *pp) -- 2.43.0

2 weeks, 1 day

[PATCH] mm/readahead: read min folio constraints under invalidate lock

by Jinchao Wang

page_cache_ra_order() and page_cache_ra_unbounded() read mapping minimum folio constraints before taking the invalidate lock, allowing concurrent changes to violate page cache invariants. Move the lookups under filemap_invalidate_lock_shared() to ensure readahead allocations respect the mapping constraints. Fixes: 47dd67532303 ("block/bdev: lift block size restrictions to 64k") Reported-by: syzbot+4d3cc33ef7a77041efa6(a)syzkaller.appspotmail.com Reported-by: syzbot+fdba5cca73fee92c69d6(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- mm/readahead.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/readahead.c b/mm/readahead.c index b415c9969176..74acd6c4f87c 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -214,7 +214,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl, unsigned long index = readahead_index(ractl); gfp_t gfp_mask = readahead_gfp_mask(mapping); unsigned long mark = ULONG_MAX, i = 0; - unsigned int min_nrpages = mapping_min_folio_nrpages(mapping); + unsigned int min_nrpages; /* * Partway through the readahead operation, we will have added @@ -232,6 +232,7 @@ void page_cache_ra_unbounded(struct readahead_control *ractl, lookahead_size); filemap_invalidate_lock_shared(mapping); index = mapping_align_index(mapping, index); + min_nrpages = mapping_min_folio_nrpages(mapping); /* * As iterator `i` is aligned to min_nrpages, round_up the @@ -467,7 +468,7 @@ void page_cache_ra_order(struct readahead_control *ractl, struct address_space *mapping = ractl->mapping; pgoff_t start = readahead_index(ractl); pgoff_t index = start; - unsigned int min_order = mapping_min_folio_order(mapping); + unsigned int min_order; pgoff_t limit = (i_size_read(mapping->host) - 1) >> PAGE_SHIFT; pgoff_t mark = index + ra->size - ra->async_size; unsigned int nofs; @@ -485,13 +486,16 @@ void page_cache_ra_order(struct readahead_control *ractl, new_order = min(mapping_max_folio_order(mapping), new_order); new_order = min_t(unsigned int, new_order, ilog2(ra->size)); - new_order = max(new_order, min_order); ra->order = new_order; /* See comment in page_cache_ra_unbounded() */ nofs = memalloc_nofs_save(); filemap_invalidate_lock_shared(mapping); + + min_order = mapping_min_folio_order(mapping); + new_order = max(new_order, min_order); + /* * If the new_order is greater than min_order and index is * already aligned to new_order, then this will be noop as index -- 2.43.0

2 weeks, 1 day

[PATCH v4 2/9] crypto: virtio: Remove duplicated virtqueue_kick in virtio_crypto_skcipher_crypt_req

by Bibo Mao

With function virtio_crypto_skcipher_crypt_req(), there is already virtqueue_kick() call with spinlock held in function __virtio_crypto_skcipher_do_req(). Remove duplicated virtqueue_kick() function call here. Fixes: d79b5d0bbf2e ("crypto: virtio - support crypto engine framework") Cc: stable(a)vger.kernel.org Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> --- drivers/crypto/virtio/virtio_crypto_skcipher_algs.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c b/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c index 1b3fb21a2a7d..11053d1786d4 100644 --- a/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c +++ b/drivers/crypto/virtio/virtio_crypto_skcipher_algs.c @@ -541,8 +541,6 @@ int virtio_crypto_skcipher_crypt_req( if (ret < 0) return ret; - virtqueue_kick(data_vq->vq); - return 0; } -- 2.39.3

2 weeks, 1 day

[PATCH v4 1/9] crypto: virtio: Add spinlock protection with virtqueue notification

by Bibo Mao

When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Cc: stable(a)vger.kernel.org Signed-off-by: Bibo Mao <maobibo(a)loongson.cn> Acked-by: Jason Wang <jasowang(a)redhat.com> --- drivers/crypto/virtio/virtio_crypto_core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/virtio/virtio_crypto_core.c b/drivers/crypto/virtio/virtio_crypto_core.c index 3d241446099c..ccc6b5c1b24b 100644 --- a/drivers/crypto/virtio/virtio_crypto_core.c +++ b/drivers/crypto/virtio/virtio_crypto_core.c @@ -75,15 +75,20 @@ static void virtcrypto_done_task(unsigned long data) struct data_queue *data_vq = (struct data_queue *)data; struct virtqueue *vq = data_vq->vq; struct virtio_crypto_request *vc_req; + unsigned long flags; unsigned int len; + spin_lock_irqsave(&data_vq->lock, flags); do { virtqueue_disable_cb(vq); while ((vc_req = virtqueue_get_buf(vq, &len)) != NULL) { + spin_unlock_irqrestore(&data_vq->lock, flags); if (vc_req->alg_cb) vc_req->alg_cb(vc_req, len); + spin_lock_irqsave(&data_vq->lock, flags); } } while (!virtqueue_enable_cb(vq)); + spin_unlock_irqrestore(&data_vq->lock, flags); } static void virtcrypto_dataq_callback(struct virtqueue *vq) -- 2.39.3

2 weeks, 1 day

[PATCH] exec: do not call sched_mm_cid_after_execve() on exec fail

by Jinchao Wang

sched_mm_cid_after_execve() is called from the failure path of bprm_execve(). At that point exec has not completed successfully, so updating the mm CID state is incorrect and can trigger a panic, as reported by syzbot. Remove the call from the exec failure path. Cc: stable(a)vger.kernel.org Reported-by: syzbot+9ca2c6e6b098bf5ae60a(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/exec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 9d5ebc9d15b0..9044a75d26ab 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1773,7 +1773,6 @@ static int bprm_execve(struct linux_binprm *bprm) if (bprm->point_of_no_return && !fatal_signal_pending(current)) force_fatal_sig(SIGSEGV); - sched_mm_cid_after_execve(current); rseq_force_update(); current->in_execve = 0; -- 2.43.0

2 weeks, 1 day

[PATCH] io_uring/rsrc: fix RLIMIT_MEMLOCK bypass via compound page accounting

by Yuhao Jiang

When multiple registered buffers share the same compound page, only the first buffer accounts for the memory via io_buffer_account_pin(). The subsequent buffers skip accounting since headpage_already_acct() returns true. When the first buffer is unregistered, the accounting is decremented, but the compound page remains pinned by the remaining buffers. This creates a state where pinned memory is not properly accounted against RLIMIT_MEMLOCK. On systems with HugeTLB pages pre-allocated, an unprivileged user can exploit this to pin memory beyond RLIMIT_MEMLOCK by cycling buffer registrations. The bypass amount is proportional to the number of available huge pages, potentially allowing gigabytes of memory to be pinned while the kernel accounting shows near-zero. Fix this by recalculating the actual pages to unaccount when unmapping a buffer. For regular pages, always unaccount. For compound pages, only unaccount if no other registered buffer references the same compound page. This ensures the accounting persists until the last buffer referencing the compound page is released. Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Fixes: 57bebf807e2a ("io_uring/rsrc: optimise registered huge pages") Cc: stable(a)vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang(a)gmail.com> --- io_uring/rsrc.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 2 deletions(-) diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c index a63474b331bf..dcf2340af5a2 100644 --- a/io_uring/rsrc.c +++ b/io_uring/rsrc.c @@ -139,15 +139,80 @@ static void io_free_imu(struct io_ring_ctx *ctx, struct io_mapped_ubuf *imu) kvfree(imu); } +/* + * Calculate pages to unaccount when unmapping a buffer. Regular pages are + * always counted. Compound pages are only counted if no other registered + * buffer references them, ensuring accounting persists until the last user. + */ +static unsigned long io_buffer_calc_unaccount(struct io_ring_ctx *ctx, + struct io_mapped_ubuf *imu) +{ + struct page *last_hpage = NULL; + unsigned long acct = 0; + unsigned int i; + + for (i = 0; i < imu->nr_bvecs; i++) { + struct page *page = imu->bvec[i].bv_page; + struct page *hpage; + unsigned int j; + + if (!PageCompound(page)) { + acct++; + continue; + } + + hpage = compound_head(page); + if (hpage == last_hpage) + continue; + last_hpage = hpage; + + /* Check if we already processed this hpage earlier in this buffer */ + for (j = 0; j < i; j++) { + if (PageCompound(imu->bvec[j].bv_page) && + compound_head(imu->bvec[j].bv_page) == hpage) + goto next_hpage; + } + + /* Only unaccount if no other buffer references this page */ + for (j = 0; j < ctx->buf_table.nr; j++) { + struct io_rsrc_node *node = ctx->buf_table.nodes[j]; + struct io_mapped_ubuf *other; + unsigned int k; + + if (!node) + continue; + other = node->buf; + if (other == imu) + continue; + + for (k = 0; k < other->nr_bvecs; k++) { + struct page *op = other->bvec[k].bv_page; + + if (!PageCompound(op)) + continue; + if (compound_head(op) == hpage) + goto next_hpage; + } + } + acct += page_size(hpage) >> PAGE_SHIFT; +next_hpage: + ; + } + return acct; +} + static void io_buffer_unmap(struct io_ring_ctx *ctx, struct io_mapped_ubuf *imu) { + unsigned long acct; + if (unlikely(refcount_read(&imu->refs) > 1)) { if (!refcount_dec_and_test(&imu->refs)) return; } - if (imu->acct_pages) - io_unaccount_mem(ctx->user, ctx->mm_account, imu->acct_pages); + acct = io_buffer_calc_unaccount(ctx, imu); + if (acct) + io_unaccount_mem(ctx->user, ctx->mm_account, acct); imu->release(imu->priv); io_free_imu(ctx, imu); } -- 2.34.1

2 weeks, 1 day

[PATCH] exec: do not call sched_mm_cid_after_execve() on exec fail

by Jinchao Wang

sched_mm_cid_after_execve() is called from the failure path of bprm_execve(). At that point exec has not completed successfully, so updating the mm CID state is incorrect and can trigger a panic, as reported by syzbot. Remove the call from the exec failure path. #syz test Cc: stable(a)vger.kernel.org Reported-by: syzbot+9ca2c6e6b098bf5ae60a(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/exec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 9d5ebc9d15b0..9044a75d26ab 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1773,7 +1773,6 @@ static int bprm_execve(struct linux_binprm *bprm) if (bprm->point_of_no_return && !fatal_signal_pending(current)) force_fatal_sig(SIGSEGV); - sched_mm_cid_after_execve(current); rseq_force_update(); current->in_execve = 0; -- 2.43.0

2 weeks, 1 day

Re: Patch "drm/xe: Enforce correct user fence signaling order using" has been added to the 6.18-stable tree

by Thomas Hellström

Hi, On Sat, 2025-12-13 at 04:38 -0500, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/xe: Enforce correct user fence signaling order using > > to the 6.18-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: > drm-xe-enforce-correct-user-fence-signaling-order-us.patch > and it can be found in the queue-6.18 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. > > (Already replied to a similar email from GregKH) Please skip this patch. The patch looks already applied and appears to be the result of an incorrect merge resolution. Thanks, Thomas > > commit e0d6df858765e6228a87c8559ccbe6826a1a6fef > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Fri Oct 31 16:40:45 2025 -0700 > > drm/xe: Enforce correct user fence signaling order using > > [ Upstream commit adda4e855ab6409a3edaa585293f1f2069ab7299 ] > > Prevent application hangs caused by out-of-order fence signaling > when > user fences are attached. Use drm_syncobj (via dma-fence-chain) > to > guarantee that each user fence signals in order, regardless of > the > signaling order of the attached fences. Ensure user fence > writebacks to > user space occur in the correct sequence. > > v7: > - Skip drm_syncbj create of error (CI) > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for > Intel GPUs") > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Link: > https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c > b/drivers/gpu/drm/xe/xe_exec_queue.c > index cb5f204c08ed6..a6efe4e8ab556 100644 > --- a/drivers/gpu/drm/xe/xe_exec_queue.c > +++ b/drivers/gpu/drm/xe/xe_exec_queue.c > @@ -344,6 +344,9 @@ void xe_exec_queue_destroy(struct kref *ref) > struct xe_exec_queue *q = container_of(ref, struct > xe_exec_queue, refcount); > struct xe_exec_queue *eq, *next; > > + if (q->ufence_syncobj) > + drm_syncobj_put(q->ufence_syncobj); > + > if (q->ufence_syncobj) > drm_syncobj_put(q->ufence_syncobj); >

2 weeks, 1 day

[PATCH V1] arm64: dts: qcom: talos: Correct UFS clocks ordering

by Pradeep P V K

The current UFS clocks does not align with their respective names, causing the ref_clk to be set to an incorrect frequency as below, which results in command timeouts. ufshcd-qcom 1d84000.ufshc: invalid ref_clk setting = 300000000 This commit fixes the issue by properly reordering the UFS clocks to match their names. Fixes: ea172f61f4fd ("arm64: dts: qcom: qcs615: Fix up UFS clocks") Cc: stable(a)vger.kernel.org Signed-off-by: Pradeep P V K <pradeep.pragallapati(a)oss.qualcomm.com> --- arch/arm64/boot/dts/qcom/talos.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi index d1dbfa3bd81c..95d26e313622 100644 --- a/arch/arm64/boot/dts/qcom/talos.dtsi +++ b/arch/arm64/boot/dts/qcom/talos.dtsi @@ -1399,10 +1399,10 @@ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>, <&gcc GCC_UFS_PHY_AHB_CLK>, <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>, - <&gcc GCC_UFS_PHY_ICE_CORE_CLK>, <&rpmhcc RPMH_CXO_CLK>, <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>, - <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>; + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_ICE_CORE_CLK>; clock-names = "core_clk", "bus_aggr_clk", "iface_clk", -- 2.17.1

2 weeks, 1 day

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror