November 2024 - Linux-stable-mirror

[PATCH V7 1/2] cpufreq: scmi: Fix cleanup path when boost enablement fails

by Sibi Sankar

Include free_cpufreq_table in the cleanup path when boost enablement fails. cc: stable(a)vger.kernel.org Fixes: a8e949d41c72 ("cpufreq: scmi: Enable boost support") Signed-off-by: Sibi Sankar <quic_sibis(a)quicinc.com> --- drivers/cpufreq/scmi-cpufreq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c index 5892c73e129d..07d6f9a9b7c8 100644 --- a/drivers/cpufreq/scmi-cpufreq.c +++ b/drivers/cpufreq/scmi-cpufreq.c @@ -287,7 +287,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) ret = cpufreq_enable_boost_support(); if (ret) { dev_warn(cpu_dev, "failed to enable boost: %d\n", ret); - goto out_free_opp; + goto out_free_table; } else { scmi_cpufreq_hw_attr[1] = &cpufreq_freq_attr_scaling_boost_freqs; scmi_cpufreq_driver.boost_enabled = true; @@ -296,6 +296,8 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) return 0; +out_free_table: + dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table); out_free_opp: dev_pm_opp_remove_all_dynamic(cpu_dev); -- 2.34.1

5 months, 2 weeks

2
1
0 0

[PATCH 6.6 00/28] fix CVE-2024-46701

by Yu Kuai

From: Yu Kuai <yukuai3(a)huawei.com> Fix patch is patch 27, relied patches are from: - patches from set [1] to add helpers to maple_tree, the last patch to improve fork() performance is not backported; - patches from set [2] to change maple_tree, and follow up fixes; - patches from set [3] to convert offset_ctx from xarray to maple_tree; Please notice that I'm not an expert in this area, and I'm afraid to make manual changes. That's why patch 16 revert the commit that is different from mainline and will cause conflict backporting new patches. patch 28 pick the original mainline patch again. (And this is what we did to fix the CVE in downstream kernels). [1] https://lore.kernel.org/all/20231027033845.90608-1-zhangpeng.00@bytedance.c… [2] https://lore.kernel.org/all/20231101171629.3612299-2-Liam.Howlett@oracle.co… [3] https://lore.kernel.org/all/170820083431.6328.16233178852085891453.stgit@91… Andrew Morton (1): lib/maple_tree.c: fix build error due to hotfix alteration Chuck Lever (5): libfs: Re-arrange locking in offset_iterate_dir() libfs: Define a minimum directory offset libfs: Add simple_offset_empty() maple_tree: Add mtree_alloc_cyclic() libfs: Convert simple directory offsets to use a Maple Tree Liam R. Howlett (12): maple_tree: remove unnecessary default labels from switch statements maple_tree: make mas_erase() more robust maple_tree: move debug check to __mas_set_range() maple_tree: add end of node tracking to the maple state maple_tree: use cached node end in mas_next() maple_tree: use cached node end in mas_destroy() maple_tree: clean up inlines for some functions maple_tree: separate ma_state node from status maple_tree: remove mas_searchable() maple_tree: use maple state end for write operations maple_tree: don't find node end in mtree_lookup_walk() maple_tree: mtree_range_walk() clean up Lorenzo Stoakes (1): maple_tree: correct tree corruption on spanning store Peng Zhang (7): maple_tree: add mt_free_one() and mt_attr() helpers maple_tree: introduce {mtree,mas}_lock_nested() maple_tree: introduce interfaces __mt_dup() and mtree_dup() maple_tree: skip other tests when BENCH is enabled maple_tree: preserve the tree attributes when destroying maple tree maple_tree: add test for mtree_dup() maple_tree: avoid checking other gaps after getting the largest gap Yu Kuai (1): Revert "maple_tree: correct tree corruption on spanning store" yangerkun (1): libfs: fix infinite directory reads for offset dir fs/libfs.c | 129 ++- include/linux/fs.h | 6 +- include/linux/maple_tree.h | 356 +++--- include/linux/mm_types.h | 3 +- lib/maple_tree.c | 1096 +++++++++++++------ lib/test_maple_tree.c | 218 ++-- mm/internal.h | 10 +- mm/shmem.c | 4 +- tools/include/linux/spinlock.h | 1 + tools/testing/radix-tree/linux/maple_tree.h | 2 +- tools/testing/radix-tree/maple.c | 390 ++++++- 11 files changed, 1564 insertions(+), 651 deletions(-) -- 2.39.2

5 months, 2 weeks

7
46
0 0

[PATCH net] gve: Flow steering trigger reset only for timeout error

by Jeroen de Borst

From: Ziwei Xiao <ziweixiao(a)google.com> When configuring flow steering rules, the driver is currently going through a reset for all errors from the device. Instead, the driver should only reset when there's a timeout error from the device. Fixes: 57718b60df9b ("gve: Add flow steering adminq commands") Cc: stable(a)vger.kernel.org Signed-off-by: Ziwei Xiao <ziweixiao(a)google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy(a)google.com> --- drivers/net/ethernet/google/gve/gve_adminq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c index e44e8b139633..060e0e674938 100644 --- a/drivers/net/ethernet/google/gve/gve_adminq.c +++ b/drivers/net/ethernet/google/gve/gve_adminq.c @@ -1248,10 +1248,10 @@ gve_adminq_configure_flow_rule(struct gve_priv *priv, sizeof(struct gve_adminq_configure_flow_rule), flow_rule_cmd); - if (err) { + if (err == -ETIME) { dev_err(&priv->pdev->dev, "Timeout to configure the flow rule, trigger reset"); gve_reset(priv, true); - } else { + } else if (!err) { priv->flow_rules_cache.rules_cache_synced = false; } -- 2.47.0.277.g8800431eea-goog

5 months, 2 weeks

2
1
0 0

[PATCH 5.10.y 0/2] Fixed perf abort when taken branch stack sampling enabled

by Shuai Xue

On x86 platform, kernel v5.10.228, perf-report command aborts due to "free(): invalid pointer" when perf-record command is run with taken branch stack sampling enabled. This regression can be reproduced with the following steps: - sudo perf record -b - sudo perf report The root cause is that bi[i].to.ms.maps does not always point to thread->maps, which is a buffer dynamically allocated by maps_new(). Instead, it may point to &machine->kmaps, while kmaps is not a pointer but a variable. The original upstream commit c1149037f65b ("perf hist: Add missing puts to hist__account_cycles") worked well because machine->kmaps had been refactored to a pointer by the previous commit 1a97cee604dc ("perf maps: Use a pointer for kmaps"). The memory leak issue, which the reverted patch intended to fix, has been solved by commit cf96b8e45a9b ("perf session: Add missing evlist__delete when deleting a session"). The root cause is that the evlist is not being deleted on exit in perf-report, perf-script, and perf-data. Consequently, the reference count of the thread increased by thread__get() in hist_entry__init() is not decremented in hist_entry__delete(). As a result, thread->maps is not properly freed. To this end, - PATCH 1/2 reverts commit a83fc293acd5c5050a4828eced4a71d2b2fffdd3 to fix the abort regression. - PATCH 2/2 backports cf96b8e45a9b ("perf session: Add missing evlist__delete when deleting a session") to fix memory leak issue. Riccardo Mancini (1): perf session: Add missing evlist__delete when deleting a session Shuai Xue (1): Revert "perf hist: Add missing puts to hist__account_cycles" tools/perf/util/hist.c | 10 +++------- tools/perf/util/session.c | 5 ++++- 2 files changed, 7 insertions(+), 8 deletions(-) -- 2.39.3

5 months, 2 weeks

2
4
0 0

[PATCH] arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer

by Dragan Simic

The way InvenSense MPU-6050 accelerometer is mounted on the user-facing side of the Pine64 PinePhone mainboard, which makes it rotated 90 degrees counter- clockwise, [1] requires the accelerometer's x- and y-axis to be swapped, and the direction of the accelerometer's y-axis to be inverted. Rectify this by adding a mount-matrix to the accelerometer definition in the Pine64 PinePhone dtsi file. [1] https://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20pla… Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone") Cc: stable(a)vger.kernel.org Helped-by: Ondrej Jirman <megi(a)xff.cz> Helped-by: Andrey Skvortsov <andrej.skvortzov(a)gmail.com> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- Notes: See also the linux-sunxi thread [2] that has led to this patch, which provides a rather detailed analysis with additional details and pictures. This patch effectively replaces the patch submitted in that thread. [2] https://lore.kernel.org/linux-sunxi/20240916204521.2033218-1-andrej.skvortz… arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi index 6eab61a12cd8..b844759f52c0 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi @@ -212,6 +212,9 @@ accelerometer@68 { interrupts = <7 5 IRQ_TYPE_EDGE_RISING>; /* PH5 */ vdd-supply = <&reg_dldo1>; vddio-supply = <&reg_dldo1>; + mount-matrix = "0", "1", "0", + "-1", "0", "0", + "0", "0", "1"; }; };

5 months, 2 weeks

4
8
0 0

+ mm-readahead-fix-large-folio-support-in-async-readahead.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/readahead: fix large folio support in async readahead has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-readahead-fix-large-folio-support-in-async-readahead.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: Yafang Shao <laoar.shao(a)gmail.com> Subject: mm/readahead: fix large folio support in async readahead Date: Fri, 8 Nov 2024 22:17:10 +0800 When testing large folio support with XFS on our servers, we observed that only a few large folios are mapped when reading large files via mmap. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don't function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Link: https://lkml.kernel.org/r/20241108141710.9721-1-laoar.shao@gmail.com Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Suggested-by: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/readahead.c~mm-readahead-fix-large-folio-support-in-async-readahead +++ a/mm/readahead.c @@ -385,6 +385,8 @@ static unsigned long get_next_ra_size(st return 4 * cur; if (cur <= max / 2) return 2 * cur; + if (cur > max) + return cur; return max; } _ Patches currently in -mm which might be from laoar.shao(a)gmail.com are mm-readahead-fix-large-folio-support-in-async-readahead.patch

5 months, 2 weeks

1
0
0 0

+ nommu-pass-null-argument-to-vma_iter_prealloc.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nommu: pass NULL argument to vma_iter_prealloc() has been added to the -mm mm-hotfixes-unstable branch. Its filename is nommu-pass-null-argument-to-vma_iter_prealloc.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: Hajime Tazaki <thehajime(a)gmail.com> Subject: nommu: pass NULL argument to vma_iter_prealloc() Date: Sat, 9 Nov 2024 07:28:34 +0900 When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call. Link: https://lkml.kernel.org/r/20241108222834.3625217-1-thehajime@gmail.com Fixes: b5df09226450 ("mm: set up vma iterator for vma_iter_prealloc() calls") Signed-off-by: Hajime Tazaki <thehajime(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/nommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/nommu.c~nommu-pass-null-argument-to-vma_iter_prealloc +++ a/mm/nommu.c @@ -573,7 +573,7 @@ static int delete_vma_from_mm(struct vm_ VMA_ITERATOR(vmi, vma->vm_mm, vma->vm_start); vma_iter_config(&vmi, vma->vm_start, vma->vm_end); - if (vma_iter_prealloc(&vmi, vma)) { + if (vma_iter_prealloc(&vmi, NULL)) { pr_warn("Allocation of vma tree for process %d failed\n", current->pid); return -ENOMEM; _ Patches currently in -mm which might be from thehajime(a)gmail.com are nommu-pass-null-argument-to-vma_iter_prealloc.patch

5 months, 2 weeks

1
0
0 0

[PATCH stable 6.11.y] netfs: reset subreq->iov_iter before netfs_clear_unread() tail clean

by Christian Ebner

Fixes file corruption issues when reading contents via ceph client. Call netfs_reset_subreq_iter() to align subreq->io_iter before calling netfs_clear_unread() to clear tail, as subreq->io_iter count and subreq->transferred might not be aligned after incomplete I/O, having the subreq's NETFS_SREQ_CLEAR_TAIL set. Based on ee4cdf7b ("netfs: Speed up buffered reading"), which introduces a fix for the issue in mainline. Fixes: 92b6cc5d ("netfs: Add iov_iters to (sub)requests to describe various buffers") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219237 Signed-off-by: Christian Ebner <c.ebner(a)proxmox.com> --- Sending this patch in an attempt to backport the fix introduced by commit ee4cdf7b ("netfs: Speed up buffered reading"), which however can not be cherry picked for older kernels, as the patch is not independent from other commits and touches a lot of unrelated (to the fix) code. fs/netfs/io.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/netfs/io.c b/fs/netfs/io.c index d6ada4eba744..500119285346 100644 --- a/fs/netfs/io.c +++ b/fs/netfs/io.c @@ -528,6 +528,7 @@ void netfs_subreq_terminated(struct netfs_io_subrequest *subreq, incomplete: if (test_bit(NETFS_SREQ_CLEAR_TAIL, &subreq->flags)) { + netfs_reset_subreq_iter(rreq, subreq); netfs_clear_unread(subreq); subreq->transferred = subreq->len; goto complete; -- 2.39.5

5 months, 2 weeks

2
5
0 0

[PATCH] spi: Fix deadlock when adding SPI controllers on SPI buses

by Hardik Gohil

From: Mark Brown <broonie(a)kernel.org> [ Upstream commit 6098475d4cb48d821bdf453c61118c56e26294f0 ] Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock. This can be easily triggered in the case of spi-mux. Reported-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Hardik Gohil <hgohil(a)mvista.com> --- This fix was not backported to v5.4 and 5.10 Along with this fix please also apply this fix on top of this spi: fix use-after-free of the add_lock mutex commit 6c53b45c71b4920b5e62f0ea8079a1da382b9434 upstream. Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: drivers/spi/spi.c | 15 +++++---------- include/linux/spi/spi.h | 3 +++ 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 0f9410e..58f1947 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -472,12 +472,6 @@ static LIST_HEAD(spi_controller_list); */ static DEFINE_MUTEX(board_lock); -/* - * Prevents addition of devices with same chip select and - * addition of devices below an unregistering controller. - */ -static DEFINE_MUTEX(spi_add_lock); - /** * spi_alloc_device - Allocate a new SPI device * @ctlr: Controller to which device is connected @@ -580,7 +574,7 @@ int spi_add_device(struct spi_device *spi) * chipselect **BEFORE** we call setup(), else we'll trash * its configuration. Lock against concurrent add() calls. */ - mutex_lock(&spi_add_lock); + mutex_lock(&ctlr->add_lock); status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check); if (status) { @@ -624,7 +618,7 @@ int spi_add_device(struct spi_device *spi) } done: - mutex_unlock(&spi_add_lock); + mutex_unlock(&ctlr->add_lock); return status; } EXPORT_SYMBOL_GPL(spi_add_device); @@ -2512,6 +2506,7 @@ int spi_register_controller(struct spi_controller *ctlr) spin_lock_init(&ctlr->bus_lock_spinlock); mutex_init(&ctlr->bus_lock_mutex); mutex_init(&ctlr->io_mutex); + mutex_init(&ctlr->add_lock); ctlr->bus_lock_flag = 0; init_completion(&ctlr->xfer_completion); if (!ctlr->max_dma_len) @@ -2657,7 +2652,7 @@ void spi_unregister_controller(struct spi_controller *ctlr) /* Prevent addition of new devices, unregister existing ones */ if (IS_ENABLED(CONFIG_SPI_DYNAMIC)) - mutex_lock(&spi_add_lock); + mutex_lock(&ctlr->add_lock); device_for_each_child(&ctlr->dev, NULL, __unregister); @@ -2688,7 +2683,7 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_unlock(&board_lock); if (IS_ENABLED(CONFIG_SPI_DYNAMIC)) - mutex_unlock(&spi_add_lock); + mutex_unlock(&ctlr->add_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index ca39b33..1b9cb90 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -483,6 +483,9 @@ struct spi_controller { /* I/O mutex */ struct mutex io_mutex; + /* Used to avoid adding the same CS twice */ + struct mutex add_lock; + /* lock and mutex for SPI bus locking */ spinlock_t bus_lock_spinlock; struct mutex bus_lock_mutex; -- 2.7.4

5 months, 2 weeks

2
1
0 0

[PATCH] drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()

by Thomas Zimmermann

The code for detecting and updating the connector status in cdn_dp_pd_event_work() has a number of problems. - It does not aquire the locks to call the detect helper and update the connector status. These are struct drm_mode_config.connection_mutex and struct drm_mode_config.mutex. - It does not use drm_helper_probe_detect(), which helps with the details of locking and detection. - It uses the connector's status field to determine a change to the connector status. The epoch_counter field is the correct one. The field signals a change even if the connector status' value did not change. Replace the code with a call to drm_connector_helper_hpd_irq_event(), which fixes all these problems. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event") Cc: Chris Zhong <zyw(a)rock-chips.com> Cc: Guenter Roeck <groeck(a)chromium.org> Cc: Sandy Huang <hjc(a)rock-chips.com> Cc: "Heiko Stübner" <heiko(a)sntech.de> Cc: Andy Yan <andy.yan(a)rock-chips.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-rockchip(a)lists.infradead.org Cc: <stable(a)vger.kernel.org> # v4.11+ --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index b04538907f95..f576b1aa86d1 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -947,9 +947,6 @@ static void cdn_dp_pd_event_work(struct work_struct *work) { struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device, event_work); - struct drm_connector *connector = &dp->connector; - enum drm_connector_status old_status; - int ret; mutex_lock(&dp->lock); @@ -1009,11 +1006,7 @@ static void cdn_dp_pd_event_work(struct work_struct *work) out: mutex_unlock(&dp->lock); - - old_status = connector->status; - connector->status = connector->funcs->detect(connector, false); - if (old_status != connector->status) - drm_kms_helper_hotplug_event(dp->drm_dev); + drm_connector_helper_hpd_irq_event(&dp->connector); } static int cdn_dp_pd_event(struct notifier_block *nb, -- 2.47.0

5 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024