December 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] mmc: mtk-sd: Fix error handle of probe function" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 291220451c775a054cedc4fab4578a1419eb6256 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120624-qualified-region-9a31@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 291220451c775a054cedc4fab4578a1419eb6256 Mon Sep 17 00:00:00 2001 From: Andy-ld Lu <andy-ld.lu(a)mediatek.com> Date: Thu, 7 Nov 2024 20:11:21 +0800 Subject: [PATCH] mmc: mtk-sd: Fix error handle of probe function In the probe function, it goes to 'release_mem' label and returns after some procedure failure. But if the clocks (partial or all) have been enabled previously, they would not be disabled in msdc_runtime_suspend, since runtime PM is not yet enabled for this case. That cause mmc related clocks always on during system suspend and block suspend flow. Below log is from a SDCard issue of MT8196 chromebook, it returns -ETIMEOUT while polling clock stable in the msdc_ungate_clock() and probe failed, but the enabled clocks could not be disabled anyway. [ 129.059253] clk_chk_dev_pm_suspend() [ 129.350119] suspend warning: msdcpll is on [ 129.354494] [ck_msdc30_1_sel : enabled, 1, 1, 191999939, ck_msdcpll_d2] [ 129.362787] [ck_msdcpll_d2 : enabled, 1, 1, 191999939, msdcpll] [ 129.371041] [ck_msdc30_1_ck : enabled, 1, 1, 191999939, ck_msdc30_1_sel] [ 129.379295] [msdcpll : enabled, 1, 1, 383999878, clk26m] Add a new 'release_clk' label and reorder the error handle functions to make sure the clocks be disabled after probe failure. Fixes: ffaea6ebfe9c ("mmc: mtk-sd: Use readl_poll_timeout instead of open-coded polling") Fixes: 7a2fa8eed936 ("mmc: mtk-sd: use devm_mmc_alloc_host") Signed-off-by: Andy-ld Lu <andy-ld.lu(a)mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: stable(a)vger.kernel.org Message-ID: <20241107121215.5201-1-andy-ld.lu(a)mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index a2750a45c1b7..022526a1f754 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -3007,7 +3007,7 @@ static int msdc_drv_probe(struct platform_device *pdev) ret = msdc_ungate_clock(host); if (ret) { dev_err(&pdev->dev, "Cannot ungate clocks!\n"); - goto release_mem; + goto release_clk; } msdc_init_hw(host); @@ -3017,14 +3017,14 @@ static int msdc_drv_probe(struct platform_device *pdev) GFP_KERNEL); if (!host->cq_host) { ret = -ENOMEM; - goto release_mem; + goto release; } host->cq_host->caps |= CQHCI_TASK_DESC_SZ_128; host->cq_host->mmio = host->base + 0x800; host->cq_host->ops = &msdc_cmdq_ops; ret = cqhci_init(host->cq_host, mmc, true); if (ret) - goto release_mem; + goto release; mmc->max_segs = 128; /* cqhci 16bit length */ /* 0 size, means 65536 so we don't have to -1 here */ @@ -3064,9 +3064,10 @@ static int msdc_drv_probe(struct platform_device *pdev) end: pm_runtime_disable(host->dev); release: - platform_set_drvdata(pdev, NULL); msdc_deinit_hw(host); +release_clk: msdc_gate_clock(host); + platform_set_drvdata(pdev, NULL); release_mem: if (host->dma.gpd) dma_free_coherent(&pdev->dev,

4 months, 2 weeks

3
2
0 0

[PATCH 6.1.y] fs/ntfs3: Fixed overflow check in mi_enum_attr()

by jianqi.ren.cn＠windriver.com

From: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> [ Upstream commit 652cfeb43d6b9aba5c7c4902bed7a7340df131fb ] Reported-by: Robert Morris <rtm(a)csail.mit.edu> Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jianqi.ren.cn(a)windriver.com <jianqi.ren.cn(a)windriver.com> --- fs/ntfs3/record.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs3/record.c b/fs/ntfs3/record.c index 7ab452710572..826a756669a3 100644 --- a/fs/ntfs3/record.c +++ b/fs/ntfs3/record.c @@ -273,7 +273,7 @@ struct ATTRIB *mi_enum_attr(struct mft_inode *mi, struct ATTRIB *attr) if (t16 > asize) return NULL; - if (t16 + le32_to_cpu(attr->res.data_size) > asize) + if (le32_to_cpu(attr->res.data_size) > asize - t16) return NULL; if (attr->name_len && -- 2.25.1

4 months, 2 weeks

3
2
0 0

[PATCH 6.1.y] drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()

by jianqi.ren.cn＠windriver.com

From: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> [ Upstream commit 2a3cfb9a24a28da9cc13d2c525a76548865e182c ] Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Signed-off-by: Nikita Zhandarovich <n.zhandarovich(a)fintech.ru> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 8dc0f70df24f..7b4d44dcb343 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -1882,14 +1882,14 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev) dc_deinit_callbacks(adev->dm.dc); #endif - if (adev->dm.dc) + if (adev->dm.dc) { dc_dmub_srv_destroy(&adev->dm.dc->ctx->dmub_srv); - - if (dc_enable_dmub_notifications(adev->dm.dc)) { - kfree(adev->dm.dmub_notify); - adev->dm.dmub_notify = NULL; - destroy_workqueue(adev->dm.delayed_hpd_wq); - adev->dm.delayed_hpd_wq = NULL; + if (dc_enable_dmub_notifications(adev->dm.dc)) { + kfree(adev->dm.dmub_notify); + adev->dm.dmub_notify = NULL; + destroy_workqueue(adev->dm.delayed_hpd_wq); + adev->dm.delayed_hpd_wq = NULL; + } } if (adev->dm.dmub_bo) -- 2.25.1

4 months, 2 weeks

2
1
0 0

[PATCH v2 6.6 6.12] KVM: x86/mmu: Ensure that kvm_release_pfn_clean() takes exact pfn from kvm_faultin_pfn()

by Nikolay Kuratov

Since 5.16 and prior to 6.13 KVM can't be used with FSDAX guest memory (PMD pages). To reproduce the issue you need to reserve guest memory with `memmap=` cmdline, create and mount FS in DAX mode (tested both XFS and ext4), see doc link below. ndctl command for test: ndctl create-namespace -v -e namespace1.0 --map=dev --mode=fsdax -a 2M Then pass memory object to qemu like: -m 8G -object memory-backend-file,id=ram0,size=8G,\ mem-path=/mnt/pmem/guestmem,share=on,prealloc=on,dump=off,align=2097152 \ -numa node,memdev=ram0,cpus=0-1 QEMU fails to run guest with error: kvm run failed Bad address and there are two warnings in dmesg: WARN_ON_ONCE(!page_count(page)) in kvm_is_zone_device_page() and WARN_ON_ONCE(folio_ref_count(folio) <= 0) in try_grab_folio() (v6.6.63) It looks like in the past assumption was made that pfn won't change from faultin_pfn() to release_pfn_clean(), e.g. see commit 4cd071d13c5c ("KVM: x86/mmu: Move calls to thp_adjust() down a level") But kvm_page_fault structure made pfn part of mutable state, so now release_pfn_clean() can take hugepage-adjusted pfn. And it works for all cases (/dev/shm, hugetlb, devdax) except fsdax. Apparently in fsdax mode faultin-pfn and adjusted-pfn may refer to different folios, so we're getting get_page/put_page imbalance. To solve this preserve faultin pfn in separate local variable and pass it in kvm_release_pfn_clean(). Patch tested for all mentioned guest memory backends with tdp_mmu={0,1}. No bug in upstream as it was solved fundamentally by commit 8dd861cc07e2 ("KVM: x86/mmu: Put refcounted pages instead of blindly releasing pfns") and related patch series. Link: https://nvdimm.docs.kernel.org/2mib_fs_dax.html Fixes: 2f6305dd5676 ("KVM: MMU: change kvm_tdp_mmu_map() arguments to kvm_page_fault") Co-developed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Reviewed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- v1 -> v2: * Instead of new struct field prefer local variable to snapshot faultin pfn as suggested by Sean Christopherson. * Tested patch for 6.1 and 6.12 arch/x86/kvm/mmu/mmu.c | 10 ++++++++-- arch/x86/kvm/mmu/paging_tmpl.h | 5 ++++- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 294775b7383b..ff85526a9d48 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4363,6 +4363,7 @@ static bool is_page_fault_stale(struct kvm_vcpu *vcpu, static int direct_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) { + kvm_pfn_t orig_pfn; int r; /* Dummy roots are used only for shadowing bad guest roots. */ @@ -4384,6 +4385,8 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault if (r != RET_PF_CONTINUE) return r; + orig_pfn = fault->pfn; + r = RET_PF_RETRY; write_lock(&vcpu->kvm->mmu_lock); @@ -4398,7 +4401,7 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault out_unlock: write_unlock(&vcpu->kvm->mmu_lock); - kvm_release_pfn_clean(fault->pfn); + kvm_release_pfn_clean(orig_pfn); return r; } @@ -4447,6 +4450,7 @@ EXPORT_SYMBOL_GPL(kvm_handle_page_fault); static int kvm_tdp_mmu_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) { + kvm_pfn_t orig_pfn; int r; if (page_fault_handle_page_track(vcpu, fault)) @@ -4464,6 +4468,8 @@ static int kvm_tdp_mmu_page_fault(struct kvm_vcpu *vcpu, if (r != RET_PF_CONTINUE) return r; + orig_pfn = fault->pfn; + r = RET_PF_RETRY; read_lock(&vcpu->kvm->mmu_lock); @@ -4474,7 +4480,7 @@ static int kvm_tdp_mmu_page_fault(struct kvm_vcpu *vcpu, out_unlock: read_unlock(&vcpu->kvm->mmu_lock); - kvm_release_pfn_clean(fault->pfn); + kvm_release_pfn_clean(orig_pfn); return r; } #endif diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index c85255073f67..c6b2c52aceac 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -777,6 +777,7 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault, static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) { struct guest_walker walker; + kvm_pfn_t orig_pfn; int r; WARN_ON_ONCE(fault->is_tdp); @@ -835,6 +836,8 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault walker.pte_access &= ~ACC_EXEC_MASK; } + orig_pfn = fault->pfn; + r = RET_PF_RETRY; write_lock(&vcpu->kvm->mmu_lock); @@ -848,7 +851,7 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault out_unlock: write_unlock(&vcpu->kvm->mmu_lock); - kvm_release_pfn_clean(fault->pfn); + kvm_release_pfn_clean(orig_pfn); return r; } -- 2.34.1

4 months, 2 weeks

3
2
0 0

[PATCH v3 06/25] ASoC: renesas: rz-ssi: Terminate all the DMA transactions

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> In case of full duplex the 1st closed stream doesn't benefit from the dmaengine_terminate_async(). Call it after the companion stream is closed. Fixes: 4f8cd05a4305 ("ASoC: sh: rz-ssi: Add full duplex support") Cc: stable(a)vger.kernel.org Reviewed-by: Biju Das <biju.das.jz(a)bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- Changes in v3: - collected tags - use proper fixes commit SHA1 and description - s/sh/renesas in patch title Changes in v2: - none sound/soc/renesas/rz-ssi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/renesas/rz-ssi.c b/sound/soc/renesas/rz-ssi.c index 6efd017aaa7f..2d8721156099 100644 --- a/sound/soc/renesas/rz-ssi.c +++ b/sound/soc/renesas/rz-ssi.c @@ -415,8 +415,12 @@ static int rz_ssi_stop(struct rz_ssi_priv *ssi, struct rz_ssi_stream *strm) rz_ssi_reg_mask_setl(ssi, SSICR, SSICR_TEN | SSICR_REN, 0); /* Cancel all remaining DMA transactions */ - if (rz_ssi_is_dma_enabled(ssi)) - dmaengine_terminate_async(strm->dma_ch); + if (rz_ssi_is_dma_enabled(ssi)) { + if (ssi->playback.dma_ch) + dmaengine_terminate_async(ssi->playback.dma_ch); + if (ssi->capture.dma_ch) + dmaengine_terminate_async(ssi->capture.dma_ch); + } rz_ssi_set_idle(ssi); -- 2.39.2

4 months, 2 weeks

3
2
0 0

[PATCH v2 1/6] arm64/mm: Reduce PA space to 48 bits when LPA2 is not enabled

by Ard Biesheuvel

From: Ard Biesheuvel <ardb(a)kernel.org> Currently, LPA2 kernel support implies support for up to 52 bits of physical addressing, and this is reflected in global definitions such as PHYS_MASK_SHIFT and MAX_PHYSMEM_BITS. This is potentially problematic, given that LPA2 hardware support is modeled as a CPU feature which can be overridden, and with LPA2 hardware support turned off, attempting to map physical regions with address bits [51:48] set (which may exist on LPA2 capable systems booting with arm64.nolva) will result in corrupted mappings with a truncated output address and bogus shareability attributes. This means that the accepted physical address range in the mapping routines should be at most 48 bits wide when LPA2 support is configured but not enabled at runtime. Fixes: 352b0395b505 ("arm64: Enable 52-bit virtual addressing for 4k and 16k granule configs") Cc: <stable(a)vger.kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- arch/arm64/include/asm/pgtable-hwdef.h | 6 ------ arch/arm64/include/asm/pgtable-prot.h | 7 +++++++ arch/arm64/include/asm/sparsemem.h | 4 +++- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h index c78a988cca93..a9136cc551cc 100644 --- a/arch/arm64/include/asm/pgtable-hwdef.h +++ b/arch/arm64/include/asm/pgtable-hwdef.h @@ -222,12 +222,6 @@ */ #define S1_TABLE_AP (_AT(pmdval_t, 3) << 61) -/* - * Highest possible physical address supported. - */ -#define PHYS_MASK_SHIFT (CONFIG_ARM64_PA_BITS) -#define PHYS_MASK ((UL(1) << PHYS_MASK_SHIFT) - 1) - #define TTBR_CNP_BIT (UL(1) << 0) /* diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h index 9f9cf13bbd95..a95f1f77bb39 100644 --- a/arch/arm64/include/asm/pgtable-prot.h +++ b/arch/arm64/include/asm/pgtable-prot.h @@ -81,6 +81,7 @@ extern unsigned long prot_ns_shared; #define lpa2_is_enabled() false #define PTE_MAYBE_SHARED PTE_SHARED #define PMD_MAYBE_SHARED PMD_SECT_S +#define PHYS_MASK_SHIFT (CONFIG_ARM64_PA_BITS) #else static inline bool __pure lpa2_is_enabled(void) { @@ -89,8 +90,14 @@ static inline bool __pure lpa2_is_enabled(void) #define PTE_MAYBE_SHARED (lpa2_is_enabled() ? 0 : PTE_SHARED) #define PMD_MAYBE_SHARED (lpa2_is_enabled() ? 0 : PMD_SECT_S) +#define PHYS_MASK_SHIFT (lpa2_is_enabled() ? CONFIG_ARM64_PA_BITS : 48) #endif +/* + * Highest possible physical address supported. + */ +#define PHYS_MASK ((UL(1) << PHYS_MASK_SHIFT) - 1) + /* * If we have userspace only BTI we don't want to mark kernel pages * guarded even if the system does support BTI. diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h index 8a8acc220371..035e0ca74e88 100644 --- a/arch/arm64/include/asm/sparsemem.h +++ b/arch/arm64/include/asm/sparsemem.h @@ -5,7 +5,9 @@ #ifndef __ASM_SPARSEMEM_H #define __ASM_SPARSEMEM_H -#define MAX_PHYSMEM_BITS CONFIG_ARM64_PA_BITS +#include <asm/pgtable-prot.h> + +#define MAX_PHYSMEM_BITS PHYS_MASK_SHIFT /* * Section size must be at least 512MB for 64K base -- 2.47.0.338.g60cca15819-goog

4 months, 2 weeks

2
1
0 0

Re: Patch "ntp: Introduce struct ntp_data" has been added to the 6.1-stable tree

by Thomas Gleixner

On Mon, Dec 09 2024 at 06:32, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > commit 57103d282a874ed716f489b7b336b8d833ba43b2 > Author: Thomas Gleixner <tglx(a)linutronix.de> > Date: Wed Sep 11 15:17:43 2024 +0200 > > ntp: Introduce struct ntp_data > > [ Upstream commit 68f66f97c5689825012877f58df65964056d4b5d ] > > All NTP data is held in static variables. That prevents the NTP code from > being reuasble for non-system time timekeepers, e.g. per PTP clock > timekeeping. > > Introduce struct ntp_data and move tick_usec into it for a start. > > No functional change. > > Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> > Signed-off-by: Anna-Maria Behnsen <anna-maria(a)linutronix.de> > Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> > Acked-by: John Stultz <jstultz(a)google.com> > Link: https://lore.kernel.org/all/20240911-devel-anna-maria-b4-timers-ptp-ntp-v1-… > Stable-dep-of: f5807b0606da ("ntp: Remove invalid cast in time offset math") I sent a backport of this change, which is a one liner: https://lore.kernel.org/stable/878qssr16f.ffs@tglx/ There is no point to backport the whole data struct change series for that. Thanks, tglx

4 months, 2 weeks

2
1
0 0

[PATCH v3 1/4] soc: qcom: pmic_glink: fix scope of __pmic_glink_lock in pmic_glink_rpmsg_probe()

by Krzysztof Kozlowski

File-scope "__pmic_glink_lock" mutex protects the file-scope "__pmic_glink", thus reference to it should be obtained under the lock, just like pmic_glink_rpmsg_remove() is doing. Otherwise we have a race during if PMIC GLINK device removal: the pmic_glink_rpmsg_probe() function could store local reference before mutex in driver removal is acquired. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Changes in v3: 1. None Changes in v2: 1. None --- drivers/soc/qcom/pmic_glink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c index caf3f63d940e..11e88053cc11 100644 --- a/drivers/soc/qcom/pmic_glink.c +++ b/drivers/soc/qcom/pmic_glink.c @@ -236,10 +236,11 @@ static void pmic_glink_pdr_callback(int state, char *svc_path, void *priv) static int pmic_glink_rpmsg_probe(struct rpmsg_device *rpdev) { - struct pmic_glink *pg = __pmic_glink; + struct pmic_glink *pg; int ret = 0; mutex_lock(&__pmic_glink_lock); + pg = __pmic_glink; if (!pg) { ret = dev_err_probe(&rpdev->dev, -ENODEV, "no pmic_glink device to attach to\n"); goto out_unlock; -- 2.43.0

4 months, 2 weeks

1
1
0 0

[PATCH v3] arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma

by Jakob Unterwurzacher

During mass manufacturing, we noticed the mmc_rx_crc_error counter, as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase above zero during nuttcp speedtests. Most of the time, this did not affect the achieved speed, but it prompted this investigation. Cycling through the rx_delay range on six boards (see table below) of various ages shows that there is a large good region from 0x12 to 0x35 where we see zero crc errors on all tested boards. The old rx_delay value (0x10) seems to have always been on the edge for the KSZ9031RNX that is usually placed on Puma. Choose "rx_delay = 0x23" to put us smack in the middle of the good region. This works fine as well with the KSZ9131RNX PHY that was used for a small number of boards during the COVID chip shortages. Board S/N PHY rx_delay good region --------- --- -------------------- Puma TT0069903 KSZ9031RNX 0x11 0x35 Puma TT0157733 KSZ9031RNX 0x11 0x35 Puma TT0681551 KSZ9031RNX 0x12 0x37 Puma TT0681156 KSZ9031RNX 0x10 0x38 Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017) Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards) Intersection of good regions = 0x12 0x35 Middle of good region = 0x23 Relates-to: PUMA-111 Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Cc: <stable(a)vger.kernel.org> Reviewed-by: Quentin Schulz <quentin.schulz(a)cherry.de> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher(a)cherry.de> --- v3: use rx_delay = 0x23 instead of 0x11, which was not enough. v2: cc stable, add "Fixes:", add omitted "there" to commit msg, add Reviewed-by. arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi index 9efcdce0f593..f9b4cd2d7daa 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi @@ -181,7 +181,7 @@ &gmac { snps,reset-active-low; snps,reset-delays-us = <0 10000 50000>; tx_delay = <0x10>; - rx_delay = <0x10>; + rx_delay = <0x23>; status = "okay"; }; -- 2.39.5

4 months, 2 weeks

3
2
0 0

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

by Krzysztof Kozlowski

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 arm64: dts: qcom: sm8650: Fix ADSP memory base and length arm64: dts: qcom: sm8650: Fix CDSP memory length 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 arm64: dts: qcom: sm6375: Fix ADSP memory length arm64: dts: qcom: sm6375: Fix CDSP memory base and length 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>

4 months, 2 weeks

4
33
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024