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

[PATCH] drm/nouveau/gsp: Prepare fwsec-sb and fwsec-frts at boot

by Lyude Paul

At the moment - the memory allocations for fwsec-sb and fwsec-frts are created as needed and released after being used. This can cause runtime suspend/resume to initially work on driver load, but then later fail on a machine that has been running for long enough with sufficiently high enough memory pressure: kworker/7:1: page allocation failure: order:5, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 7 UID: 0 PID: 875159 Comm: kworker/7:1 Not tainted 6.17.8-300.fc43.x86_64 #1 PREEMPT(lazy) Hardware name: SLIMBOOK Executive/Executive, BIOS N.1.10GRU06 02/02/2024 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 warn_alloc+0x163/0x190 ? __alloc_pages_direct_compact+0x1b3/0x220 __alloc_pages_slowpath.constprop.0+0x57a/0xb10 __alloc_frozen_pages_noprof+0x334/0x350 __alloc_pages_noprof+0xe/0x20 __dma_direct_alloc_pages.isra.0+0x1eb/0x330 dma_direct_alloc_pages+0x3c/0x190 dma_alloc_pages+0x29/0x130 nvkm_firmware_ctor+0x1ae/0x280 [nouveau] nvkm_falcon_fw_ctor+0x3e/0x60 [nouveau] nvkm_gsp_fwsec+0x10e/0x2c0 [nouveau] ? sysvec_apic_timer_interrupt+0xe/0x90 nvkm_gsp_fwsec_sb+0x27/0x70 [nouveau] tu102_gsp_fini+0x65/0x110 [nouveau] ? ktime_get+0x3c/0xf0 nvkm_subdev_fini+0x67/0xc0 [nouveau] nvkm_device_fini+0x94/0x140 [nouveau] nvkm_udevice_fini+0x50/0x70 [nouveau] nvkm_object_fini+0xb1/0x140 [nouveau] nvkm_object_fini+0x70/0x140 [nouveau] ? __pfx_pci_pm_runtime_suspend+0x10/0x10 nouveau_do_suspend+0xe4/0x170 [nouveau] nouveau_pmops_runtime_suspend+0x3e/0xb0 [nouveau] pci_pm_runtime_suspend+0x67/0x1a0 ? __pfx_pci_pm_runtime_suspend+0x10/0x10 __rpm_callback+0x45/0x1f0 ? __pfx_pci_pm_runtime_suspend+0x10/0x10 rpm_callback+0x6d/0x80 rpm_suspend+0xe5/0x5e0 ? finish_task_switch.isra.0+0x99/0x2c0 pm_runtime_work+0x98/0xb0 process_one_work+0x18f/0x350 worker_thread+0x25a/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xf9/0x240 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0xf1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> The reason this happens is because the fwsec-sb and fwsec-frts firmware images only support being booted from a contiguous coherent sysmem allocation. If a system runs into enough memory fragmentation from memory pressure, such as what can happen on systems with low amounts of memory, this can lead to a situation where it later becomes impossible to find space for a large enough contiguous allocation to hold each firmware image. As such, we fail to allocate memory for the falcon firmware images - fail to boot the GPU, and the driver falls over. Since this firmware can't use non-contiguous allocations, the best solution to avoid this issue is to simply allocate the memory for both fwsec-sb and fwsec-frts during initial driver load, and reuse said allocations whenever either firmware image needs to be used. We then release the memory allocations on driver unload. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 594766ca3e53 ("drm/nouveau/gsp: move booter handling to GPU-specific code") Cc: <stable(a)vger.kernel.org> # v6.16+ --- .../gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 5 ++ .../gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 56 ++++++++++++++----- .../gpu/drm/nouveau/nvkm/subdev/gsp/priv.h | 8 ++- .../drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 11 +++- .../gpu/drm/nouveau/nvkm/subdev/gsp/tu102.c | 4 ++ 5 files changed, 68 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h index 226c7ec56b8ed..608ef5189eddb 100644 --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h @@ -73,6 +73,11 @@ struct nvkm_gsp { const struct firmware *bl; const struct firmware *rm; + + struct { + struct nvkm_falcon_fw sb; + struct nvkm_falcon_fw frts; + } falcon; } fws; struct nvkm_firmware fw; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c index 5b721bd9d7994..be9a0b103aa1f 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c @@ -259,18 +259,16 @@ nvkm_gsp_fwsec_v3(struct nvkm_gsp *gsp, const char *name, } static int -nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) +nvkm_gsp_fwsec_init(struct nvkm_gsp *gsp, struct nvkm_falcon_fw *fw, const char *name, u32 init_cmd) { struct nvkm_subdev *subdev = &gsp->subdev; struct nvkm_device *device = subdev->device; struct nvkm_bios *bios = device->bios; const union nvfw_falcon_ucode_desc *desc; struct nvbios_pmuE flcn_ucode; - u8 idx, ver, hdr; u32 data; u16 size, vers; - struct nvkm_falcon_fw fw = {}; - u32 mbox0 = 0; + u8 idx, ver, hdr; int ret; /* Lookup in VBIOS. */ @@ -291,8 +289,8 @@ nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) vers = (desc->v2.Hdr & 0x0000ff00) >> 8; switch (vers) { - case 2: ret = nvkm_gsp_fwsec_v2(gsp, name, &desc->v2, size, init_cmd, &fw); break; - case 3: ret = nvkm_gsp_fwsec_v3(gsp, name, &desc->v3, size, init_cmd, &fw); break; + case 2: ret = nvkm_gsp_fwsec_v2(gsp, name, &desc->v2, size, init_cmd, fw); break; + case 3: ret = nvkm_gsp_fwsec_v3(gsp, name, &desc->v3, size, init_cmd, fw); break; default: nvkm_error(subdev, "%s(v%d): version unknown\n", name, vers); return -EINVAL; @@ -303,15 +301,19 @@ nvkm_gsp_fwsec(struct nvkm_gsp *gsp, const char *name, u32 init_cmd) return ret; } - /* Boot. */ - ret = nvkm_falcon_fw_boot(&fw, subdev, true, &mbox0, NULL, 0, 0); - nvkm_falcon_fw_dtor(&fw); - if (ret) - return ret; - return 0; } +static int +nvkm_gsp_fwsec_boot(struct nvkm_gsp *gsp, struct nvkm_falcon_fw *fw) +{ + struct nvkm_subdev *subdev = &gsp->subdev; + u32 mbox0 = 0; + + /* Boot */ + return nvkm_falcon_fw_boot(fw, subdev, true, &mbox0, NULL, 0, 0); +} + int nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) { @@ -320,7 +322,7 @@ nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) int ret; u32 err; - ret = nvkm_gsp_fwsec(gsp, "fwsec-sb", NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB); + ret = nvkm_gsp_fwsec_boot(gsp, &gsp->fws.falcon.sb); if (ret) return ret; @@ -334,6 +336,19 @@ nvkm_gsp_fwsec_sb(struct nvkm_gsp *gsp) return 0; } +int +nvkm_gsp_fwsec_sb_ctor(struct nvkm_gsp *gsp) +{ + return nvkm_gsp_fwsec_init(gsp, &gsp->fws.falcon.sb, "fwsec-sb", + NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB); +} + +void +nvkm_gsp_fwsec_sb_dtor(struct nvkm_gsp *gsp) +{ + nvkm_falcon_fw_dtor(&gsp->fws.falcon.sb); +} + int nvkm_gsp_fwsec_frts(struct nvkm_gsp *gsp) { @@ -342,7 +357,7 @@ nvkm_gsp_fwsec_frts(struct nvkm_gsp *gsp) int ret; u32 err, wpr2_lo, wpr2_hi; - ret = nvkm_gsp_fwsec(gsp, "fwsec-frts", NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS); + ret = nvkm_gsp_fwsec_boot(gsp, &gsp->fws.falcon.frts); if (ret) return ret; @@ -358,3 +373,16 @@ nvkm_gsp_fwsec_frts(struct nvkm_gsp *gsp) nvkm_debug(subdev, "fwsec-frts: WPR2 @ %08x - %08x\n", wpr2_lo, wpr2_hi); return 0; } + +int +nvkm_gsp_fwsec_frts_ctor(struct nvkm_gsp *gsp) +{ + return nvkm_gsp_fwsec_init(gsp, &gsp->fws.falcon.frts, "fwsec-frts", + NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS); +} + +void +nvkm_gsp_fwsec_frts_dtor(struct nvkm_gsp *gsp) +{ + nvkm_falcon_fw_dtor(&gsp->fws.falcon.frts); +} diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h index c3494b7ac572b..d0ce34b5806c2 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/priv.h @@ -5,8 +5,14 @@ #include <rm/gpu.h> enum nvkm_acr_lsf_id; -int nvkm_gsp_fwsec_frts(struct nvkm_gsp *); + +int nvkm_gsp_fwsec_sb_ctor(struct nvkm_gsp *); int nvkm_gsp_fwsec_sb(struct nvkm_gsp *); +void nvkm_gsp_fwsec_sb_dtor(struct nvkm_gsp *); + +int nvkm_gsp_fwsec_frts_ctor(struct nvkm_gsp *); +int nvkm_gsp_fwsec_frts(struct nvkm_gsp *); +void nvkm_gsp_fwsec_frts_dtor(struct nvkm_gsp *); struct nvkm_gsp_fwif { int version; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c index 32e6a065d6d7a..33db4bad44ef5 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c @@ -1817,12 +1817,16 @@ r535_gsp_rm_boot_ctor(struct nvkm_gsp *gsp) RM_RISCV_UCODE_DESC *desc; int ret; + ret = nvkm_gsp_fwsec_sb_ctor(gsp); + if (ret) + return ret; + hdr = nvfw_bin_hdr(&gsp->subdev, fw->data); desc = (void *)fw->data + hdr->header_offset; ret = nvkm_gsp_mem_ctor(gsp, hdr->data_size, &gsp->boot.fw); if (ret) - return ret; + goto dtor_fwsec; memcpy(gsp->boot.fw.data, fw->data + hdr->data_offset, hdr->data_size); @@ -1831,6 +1835,9 @@ r535_gsp_rm_boot_ctor(struct nvkm_gsp *gsp) gsp->boot.manifest_offset = desc->manifestOffset; gsp->boot.app_version = desc->appVersion; return 0; +dtor_fwsec: + nvkm_gsp_fwsec_sb_dtor(gsp); + return ret; } static const struct nvkm_firmware_func @@ -2087,6 +2094,7 @@ r535_gsp_dtor(struct nvkm_gsp *gsp) nvkm_gsp_radix3_dtor(gsp, &gsp->radix3); nvkm_gsp_mem_dtor(&gsp->sig); nvkm_firmware_dtor(&gsp->fw); + nvkm_gsp_fwsec_sb_dtor(gsp); nvkm_falcon_fw_dtor(&gsp->booter.unload); nvkm_falcon_fw_dtor(&gsp->booter.load); @@ -2105,6 +2113,7 @@ r535_gsp_dtor(struct nvkm_gsp *gsp) nvkm_gsp_mem_dtor(&gsp->rmargs); nvkm_gsp_mem_dtor(&gsp->wpr_meta); nvkm_gsp_mem_dtor(&gsp->shm.mem); + nvkm_gsp_fwsec_frts_dtor(gsp); r535_gsp_libos_debugfs_fini(gsp); diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/tu102.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/tu102.c index 81e56da0474a1..b9047da609b81 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/tu102.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/tu102.c @@ -331,6 +331,10 @@ tu102_gsp_oneinit(struct nvkm_gsp *gsp) if (ret) return ret; + ret = nvkm_gsp_fwsec_frts_ctor(gsp); + if (WARN_ON(ret)) + return ret; + ret = nvkm_gsp_fwsec_frts(gsp); if (WARN_ON(ret)) return ret; base-commit: 62433efe0b06042d8016ba0713d801165a939229 -- 2.52.0

1 week, 1 day

1
1
0 0

[PATCH] soc: ti: k3-socinfo: fix regmap leak on probe failure

by Johan Hovold

The mmio regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: a5caf03188e4 ("soc: ti: k3-socinfo: Do not use syscon helper to build regmap") Cc: stable(a)vger.kernel.org # 6.15 Cc: Andrew Davis <afd(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/soc/ti/k3-socinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c index 50c170a995f9..42275cb5ba1c 100644 --- a/drivers/soc/ti/k3-socinfo.c +++ b/drivers/soc/ti/k3-socinfo.c @@ -141,7 +141,7 @@ static int k3_chipinfo_probe(struct platform_device *pdev) if (IS_ERR(base)) return PTR_ERR(base); - regmap = regmap_init_mmio(dev, base, &k3_chipinfo_regmap_cfg); + regmap = devm_regmap_init_mmio(dev, base, &k3_chipinfo_regmap_cfg); if (IS_ERR(regmap)) return PTR_ERR(regmap); -- 2.51.2

1 week, 1 day

2
1
0 0

[PATCH] phy: ti: gmii-sel: fix regmap leak on probe failure

by Johan Hovold

The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 5ab90f40121a ("phy: ti: gmii-sel: Do not use syscon helper to build regmap") Cc: stable(a)vger.kernel.org # 6.14 Cc: Andrew Davis <afd(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/phy/ti/phy-gmii-sel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c index 50adabb867cb..26209a89703a 100644 --- a/drivers/phy/ti/phy-gmii-sel.c +++ b/drivers/phy/ti/phy-gmii-sel.c @@ -512,7 +512,7 @@ static int phy_gmii_sel_probe(struct platform_device *pdev) return dev_err_probe(dev, PTR_ERR(base), "failed to get base memory resource\n"); - priv->regmap = regmap_init_mmio(dev, base, &phy_gmii_sel_regmap_cfg); + priv->regmap = devm_regmap_init_mmio(dev, base, &phy_gmii_sel_regmap_cfg); if (IS_ERR(priv->regmap)) return dev_err_probe(dev, PTR_ERR(priv->regmap), "Failed to get syscon\n"); -- 2.51.2

1 week, 1 day

2
1
0 0

[PATCH] mux: mmio: fix regmap leak on probe failure

by Johan Hovold

The mmio regmap that may be allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 61de83fd8256 ("mux: mmio: Do not use syscon helper to build regmap") Cc: stable(a)vger.kernel.org # 6.16 Cc: Andrew Davis <afd(a)ti.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/mux/mmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c index 9993ce38a818..5b0171d19d43 100644 --- a/drivers/mux/mmio.c +++ b/drivers/mux/mmio.c @@ -58,7 +58,7 @@ static int mux_mmio_probe(struct platform_device *pdev) if (IS_ERR(base)) regmap = ERR_PTR(-ENODEV); else - regmap = regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); + regmap = devm_regmap_init_mmio(dev, base, &mux_mmio_regmap_cfg); /* Fallback to checking the parent node on "real" errors. */ if (IS_ERR(regmap) && regmap != ERR_PTR(-EPROBE_DEFER)) { regmap = dev_get_regmap(dev->parent, NULL); -- 2.51.2

1 week, 1 day

2
1
0 0

[PATCH v2] drm/amdgpu: Forward VMID reservation errors

by Natalie Vock

Otherwise userspace may be fooled into believing it has a reserved VMID when in reality it doesn't, ultimately leading to GPU hangs when SPM is used. Fixes: 80e709ee6ecc ("drm/amdgpu: add option params to enforce process isolation between graphics and compute") Cc: stable(a)vger.kernel.org Signed-off-by: Natalie Vock <natalie.vock(a)gmx.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 61820166efbf6..1479742556991 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2921,8 +2921,7 @@ int amdgpu_vm_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) switch (args->in.op) { case AMDGPU_VM_OP_RESERVE_VMID: /* We only have requirement to reserve vmid from gfxhub */ - amdgpu_vmid_alloc_reserved(adev, vm, AMDGPU_GFXHUB(0)); - break; + return amdgpu_vmid_alloc_reserved(adev, vm, AMDGPU_GFXHUB(0)); case AMDGPU_VM_OP_UNRESERVE_VMID: amdgpu_vmid_free_reserved(adev, vm, AMDGPU_GFXHUB(0)); break; -- 2.51.2

1 week, 1 day

3
2
0 0

+ mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Subject: mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free Date: Mon, 1 Dec 2025 11:30:09 +0530 When page isolation loops indefinitely during memory offline, reading /proc/sys/vm/percpu_pagelist_high_fraction blocks on pcp_batch_high_lock, causing hung task warnings. Make procfs reads lock-free since percpu_pagelist_high_fraction is a simple integer with naturally atomic reads, writers still serialize via the mutex. This prevents hung task warnings when reading the procfs file during long-running memory offline operations. Link: https://lkml.kernel.org/r/20251201060009.1420792-1-aboorvad@linux.ibm.com Signed-off-by: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Cc: Brendan Jackman <jackmanb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/page_alloc.c~mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free +++ a/mm/page_alloc.c @@ -6611,11 +6611,14 @@ static int percpu_pagelist_high_fraction int old_percpu_pagelist_high_fraction; int ret; + if (!write) + return proc_dointvec_minmax(table, write, buffer, length, ppos); + mutex_lock(&pcp_batch_high_lock); old_percpu_pagelist_high_fraction = percpu_pagelist_high_fraction; ret = proc_dointvec_minmax(table, write, buffer, length, ppos); - if (!write || ret < 0) + if (ret < 0) goto out; /* Sanity checking to avoid pcp imbalance */ _ Patches currently in -mm which might be from aboorvad(a)linux.ibm.com are mm-page_alloc-make-percpu_pagelist_high_fraction-reads-lock-free.patch

1 week, 1 day

1
0
0 0

[PATCH v1] Revert "drm: bridge: ti-sn65dsi83: Add error recovery mechanism"

by Francesco Dolcini

From: Francesco Dolcini <francesco.dolcini(a)toradex.com> This reverts commit ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism"). The reverted commit introduces a regression on Verdin AM62, and potentially on more devices, not being able to generate a clock that the TI SN65DSI83 PLL can lock to, with the display periodically blinking. Verdin AM62 SoM has a Toshiba TC358778 DPI to DSI bridge, that can be connected to an LVDS display over a TI SN65DSI83 bridge. Before this change despite the TI SN65DSI83 reporting with a debug print a PLL locking error the display was working fine with no visible glitches. The reasons for this issue was investigated without getting to a final conclusion: - the DPI clock was measure and it is stable/accurate - the DSI clock was not possible to measure, but this setup is used with other display/bridges with no known issues - the DSI clock is configured in continuous mode - the actual DSI clock generated from the TC358778 is generate with a PLL from a 25MHz reference clock - it's not clear why some frequencies are working and some are not, for example 50000000, 68750000, 72750000, 75000000 frequencies are fine, while 69750000, 71100000, 72500000 are not Given that the safest approach is to just revert the commit, till a proper solution for error recovery that is not introducing regression is figured out. Reported-by: João Paulo Gonçalves <jpaulo.silvagoncalves(a)gmail.com> Closes: https://lore.kernel.org/all/bhkn6hley4xrol5o3ytn343h4unkwsr26p6s6ltcwexnrsj… Fixes: ad5c6ecef27e ("drm: bridge: ti-sn65dsi83: Add error recovery mechanism") Cc: stable(a)vger.kernel.org Signed-off-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> --- Cc: Herve Codina <herve.codina(a)bootlin.com> Cc: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> Cc: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 136 -------------------------- 1 file changed, 136 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 033c44326552..cf627aff569b 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -35,12 +35,9 @@ #include <linux/of_graph.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> -#include <linux/timer.h> -#include <linux/workqueue.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> -#include <drm/drm_bridge_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_of.h> #include <drm/drm_print.h> @@ -161,9 +158,6 @@ struct sn65dsi83 { bool lvds_dual_link_even_odd_swap; int lvds_vod_swing_conf[2]; int lvds_term_conf[2]; - int irq; - struct delayed_work monitor_work; - struct work_struct reset_work; }; static const struct regmap_range sn65dsi83_readable_ranges[] = { @@ -369,100 +363,6 @@ static u8 sn65dsi83_get_dsi_div(struct sn65dsi83 *ctx) return dsi_div - 1; } -static int sn65dsi83_reset_pipe(struct sn65dsi83 *sn65dsi83) -{ - struct drm_modeset_acquire_ctx ctx; - int err; - - /* - * Reset active outputs of the related CRTC. - * - * This way, drm core will reconfigure each components in the CRTC - * outputs path. In our case, this will force the previous component to - * go back in LP11 mode and so allow the reconfiguration of SN65DSI83 - * bridge. - * - * Keep the lock during the whole operation to be atomic. - */ - - drm_modeset_acquire_init(&ctx, 0); - - dev_warn(sn65dsi83->dev, "reset the pipe\n"); - -retry: - err = drm_bridge_helper_reset_crtc(&sn65dsi83->bridge, &ctx); - if (err == -EDEADLK) { - drm_modeset_backoff(&ctx); - goto retry; - } - - drm_modeset_drop_locks(&ctx); - drm_modeset_acquire_fini(&ctx); - - return 0; -} - -static void sn65dsi83_reset_work(struct work_struct *ws) -{ - struct sn65dsi83 *ctx = container_of(ws, struct sn65dsi83, reset_work); - int ret; - - /* Reset the pipe */ - ret = sn65dsi83_reset_pipe(ctx); - if (ret) { - dev_err(ctx->dev, "reset pipe failed %pe\n", ERR_PTR(ret)); - return; - } - if (ctx->irq) - enable_irq(ctx->irq); -} - -static void sn65dsi83_handle_errors(struct sn65dsi83 *ctx) -{ - unsigned int irq_stat; - int ret; - - /* - * Schedule a reset in case of: - * - the bridge doesn't answer - * - the bridge signals an error - */ - - ret = regmap_read(ctx->regmap, REG_IRQ_STAT, &irq_stat); - if (ret || irq_stat) { - /* - * IRQ acknowledged is not always possible (the bridge can be in - * a state where it doesn't answer anymore). To prevent an - * interrupt storm, disable interrupt. The interrupt will be - * after the reset. - */ - if (ctx->irq) - disable_irq_nosync(ctx->irq); - - schedule_work(&ctx->reset_work); - } -} - -static void sn65dsi83_monitor_work(struct work_struct *work) -{ - struct sn65dsi83 *ctx = container_of(to_delayed_work(work), - struct sn65dsi83, monitor_work); - - sn65dsi83_handle_errors(ctx); - - schedule_delayed_work(&ctx->monitor_work, msecs_to_jiffies(1000)); -} - -static void sn65dsi83_monitor_start(struct sn65dsi83 *ctx) -{ - schedule_delayed_work(&ctx->monitor_work, msecs_to_jiffies(1000)); -} - -static void sn65dsi83_monitor_stop(struct sn65dsi83 *ctx) -{ - cancel_delayed_work_sync(&ctx->monitor_work); -} - static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge, struct drm_atomic_state *state) { @@ -650,15 +550,6 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); if (pval) dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval); - - if (ctx->irq) { - /* Enable irq to detect errors */ - regmap_write(ctx->regmap, REG_IRQ_GLOBAL, REG_IRQ_GLOBAL_IRQ_EN); - regmap_write(ctx->regmap, REG_IRQ_EN, 0xff); - } else { - /* Use the polling task */ - sn65dsi83_monitor_start(ctx); - } } static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, @@ -667,15 +558,6 @@ static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge); int ret; - if (ctx->irq) { - /* Disable irq */ - regmap_write(ctx->regmap, REG_IRQ_EN, 0x0); - regmap_write(ctx->regmap, REG_IRQ_GLOBAL, 0x0); - } else { - /* Stop the polling task */ - sn65dsi83_monitor_stop(ctx); - } - /* Put the chip in reset, pull EN line low, and assure 10ms reset low timing. */ gpiod_set_value_cansleep(ctx->enable_gpio, 0); usleep_range(10000, 11000); @@ -925,14 +807,6 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx) return 0; } -static irqreturn_t sn65dsi83_irq(int irq, void *data) -{ - struct sn65dsi83 *ctx = data; - - sn65dsi83_handle_errors(ctx); - return IRQ_HANDLED; -} - static int sn65dsi83_probe(struct i2c_client *client) { const struct i2c_device_id *id = i2c_client_get_device_id(client); @@ -946,8 +820,6 @@ static int sn65dsi83_probe(struct i2c_client *client) return PTR_ERR(ctx); ctx->dev = dev; - INIT_WORK(&ctx->reset_work, sn65dsi83_reset_work); - INIT_DELAYED_WORK(&ctx->monitor_work, sn65dsi83_monitor_work); if (dev->of_node) { model = (enum sn65dsi83_model)(uintptr_t) @@ -972,14 +844,6 @@ static int sn65dsi83_probe(struct i2c_client *client) if (IS_ERR(ctx->regmap)) return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to get regmap\n"); - if (client->irq) { - ctx->irq = client->irq; - ret = devm_request_threaded_irq(ctx->dev, ctx->irq, NULL, sn65dsi83_irq, - IRQF_ONESHOT, dev_name(ctx->dev), ctx); - if (ret) - return dev_err_probe(dev, ret, "failed to request irq\n"); - } - dev_set_drvdata(dev, ctx); i2c_set_clientdata(client, ctx); -- 2.47.3

1 week, 1 day

4
3
0 0

[PATCH] crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode

by Thorsten Blum

The local variable 'i' is initialized with -EINVAL, but the for loop immediately overwrites it and -EINVAL is never returned. If no empty compression mode can be found, the function would return the out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid array access in add_iaa_compression_mode(). Fix both issues by returning either a valid index or -EINVAL. Cc: stable(a)vger.kernel.org Fixes: b190447e0fa3 ("crypto: iaa - Add compression mode management along with fixed mode") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/crypto/intel/iaa/iaa_crypto_main.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/intel/iaa/iaa_crypto_main.c b/drivers/crypto/intel/iaa/iaa_crypto_main.c index 23f585219fb4..8ee2a55ec449 100644 --- a/drivers/crypto/intel/iaa/iaa_crypto_main.c +++ b/drivers/crypto/intel/iaa/iaa_crypto_main.c @@ -221,15 +221,13 @@ static struct iaa_compression_mode *iaa_compression_modes[IAA_COMP_MODES_MAX]; static int find_empty_iaa_compression_mode(void) { - int i = -EINVAL; + int i; - for (i = 0; i < IAA_COMP_MODES_MAX; i++) { - if (iaa_compression_modes[i]) - continue; - break; - } + for (i = 0; i < IAA_COMP_MODES_MAX; i++) + if (!iaa_compression_modes[i]) + return i; - return i; + return -EINVAL; } static struct iaa_compression_mode *find_iaa_compression_mode(const char *name, int *idx) -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

1 week, 1 day

2
1
0 0

+ x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: x86/kexec: add a sanity check on previous kernel's ima kexec buffer has been added to the -mm mm-hotfixes-unstable branch. Its filename is x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Subject: x86/kexec: add a sanity check on previous kernel's ima kexec buffer Date: Wed, 12 Nov 2025 11:30:02 -0800 When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) �� not-present page Other architectures already validate the range with page_is_ram(), as done in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Link: https://lkml.kernel.org/r/20251112193005.3772542-1-harshit.m.mogalapalli@or… Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Reported-by: Paul Webb <paul.x.webb(a)oracle.com> Reviewed-by: Jonathan McDowell <noodles(a)meta.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Ard Biesheuvel <ardb(a)kernel.org> Cc: Borislav Betkov <bp(a)alien8.de> Cc: guoweikang <guoweikang.kernel(a)gmail.com> Cc: Henry Willard <henry.willard(a)oracle.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jiri Bohac <jbohac(a)suse.cz> Cc: Joel Granados <joel.granados(a)kernel.org> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Sohil Mehta <sohil.mehta(a)intel.com> Cc: Sourabh Jain <sourabhjain(a)linux.ibm.com> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: Yifei Liu <yifei.l.liu(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/kernel/setup.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/arch/x86/kernel/setup.c~x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer +++ a/arch/x86/kernel/setup.c @@ -439,9 +439,23 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) { + unsigned long start_pfn, end_pfn; + if (!ima_kexec_buffer_size) return -ENOENT; + /* + * Calculate the PFNs for the buffer and ensure + * they are with in addressable memory. + */ + start_pfn = PFN_DOWN(ima_kexec_buffer_phys); + end_pfn = PFN_DOWN(ima_kexec_buffer_phys + ima_kexec_buffer_size - 1); + if (!pfn_range_is_mapped(start_pfn, end_pfn)) { + pr_warn("IMA buffer at 0x%llx, size = 0x%zx beyond memory\n", + ima_kexec_buffer_phys, ima_kexec_buffer_size); + return -EINVAL; + } + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size; _ Patches currently in -mm which might be from harshit.m.mogalapalli(a)oracle.com are x86-kexec-add-a-sanity-check-on-previous-kernels-ima-kexec-buffer.patch

1 week, 1 day

1
0
0 0

FAILED: patch "[PATCH] xhci: fix stale flag preventig URBs after link state error is" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x b69dfcab6894b1fed5362a364411502a7469fce3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120146-coaster-huff-141a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b69dfcab6894b1fed5362a364411502a7469fce3 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Fri, 7 Nov 2025 18:28:16 +0200 Subject: [PATCH] xhci: fix stale flag preventig URBs after link state error is cleared A usb device caught behind a link in ss.Inactive error state needs to be reset to recover. A VDEV_PORT_ERROR flag is used to track this state, preventing new transfers from being queued until error is cleared. This flag may be left uncleared if link goes to error state between two resets, and print the following message: "xhci_hcd 0000:00:14.0: Can't queue urb, port error, link inactive" Fix setting and clearing the flag. The flag is cleared after hub driver has successfully reset the device when hcd->reset_device is called. xhci-hcd issues an internal "reset device" command in this callback, and clear all flags once the command completes successfully. This command may complete with a context state error if slot was recently reset and is already in the defauilt state. This is treated as a success but flag was left uncleared. The link state field is also unreliable if port is currently in reset, so don't set the flag in active reset cases. Also clear the flag immediately when link is no longer in ss.Inactive state and port event handler detects a completed reset. This issue was discovered while debugging kernel bugzilla issue 220491. It is likely one small part of the problem, causing some of the failures, but root cause remains unknown Link: https://bugzilla.kernel.org/show_bug.cgi?id=220491 Fixes: b8c3b718087b ("usb: xhci: Don't try to recover an endpoint if port is in error state.") Cc: stable(a)vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://patch.msgid.link/20251107162819.1362579-2-mathias.nyman@linux.intel… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 8e209aa33ea7..5bdcf9ab2b99 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1985,6 +1985,7 @@ static void xhci_cavium_reset_phy_quirk(struct xhci_hcd *xhci) static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) { + struct xhci_virt_device *vdev = NULL; struct usb_hcd *hcd; u32 port_id; u32 portsc, cmd_reg; @@ -2016,6 +2017,9 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) goto cleanup; } + if (port->slot_id) + vdev = xhci->devs[port->slot_id]; + /* We might get interrupts after shared_hcd is removed */ if (port->rhub == &xhci->usb3_rhub && xhci->shared_hcd == NULL) { xhci_dbg(xhci, "ignore port event for removed USB3 hcd\n"); @@ -2038,10 +2042,11 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) usb_hcd_resume_root_hub(hcd); } - if (hcd->speed >= HCD_USB3 && - (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { - if (port->slot_id && xhci->devs[port->slot_id]) - xhci->devs[port->slot_id]->flags |= VDEV_PORT_ERROR; + if (vdev && (portsc & PORT_PLS_MASK) == XDEV_INACTIVE) { + if (!(portsc & PORT_RESET)) + vdev->flags |= VDEV_PORT_ERROR; + } else if (vdev && portsc & PORT_RC) { + vdev->flags &= ~VDEV_PORT_ERROR; } if ((portsc & PORT_PLC) && (portsc & PORT_PLS_MASK) == XDEV_RESUME) { @@ -2099,7 +2104,7 @@ static void handle_port_status(struct xhci_hcd *xhci, union xhci_trb *event) * so the roothub behavior is consistent with external * USB 3.0 hub behavior. */ - if (port->slot_id && xhci->devs[port->slot_id]) + if (vdev) xhci_ring_device(xhci, port->slot_id); if (bus_state->port_remote_wakeup & (1 << hcd_portnum)) { xhci_test_and_clear_bit(xhci, port, PORT_PLC); diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 0cb45b95e4f5..a148a1280126 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4007,6 +4007,7 @@ static int xhci_discover_or_reset_device(struct usb_hcd *hcd, xhci_get_slot_state(xhci, virt_dev->out_ctx)); xhci_dbg(xhci, "Not freeing device rings.\n"); /* Don't treat this as an error. May change my mind later. */ + virt_dev->flags = 0; ret = 0; goto command_cleanup; case COMP_SUCCESS:

1 week, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror