April 2025 - Linux-stable-mirror

[PATCH 1/2] drm/xe/dma_buf: stop relying on placement in unmap

by Matthew Auld

The is_vram() is checking the current placement, however if we consider exported VRAM with dynamic dma-buf, it looks possible for the xe driver to async evict the memory, notifying the importer, however importer does not have to call unmap_attachment() immediately, but rather just as "soon as possible", like when the dma-resv idles. Following from this we would then pipeline the move, attaching the fence to the manager, and then update the current placement. But when the unmap_attachment() runs at some later point we might see that is_vram() is now false, and take the complete wrong path when dma-unmapping the sg, leading to explosions. To fix this check if the sgl was mapping a struct page. v2: - The attachment can be mapped multiple times it seems, so we can't really rely on encoding something in the attachment->priv. Instead see if the page_link has an encoded struct page. For vram we expect this to be NULL. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4563 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_dma_buf.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c index f67803e15a0e..f7a20264ea33 100644 --- a/drivers/gpu/drm/xe/xe_dma_buf.c +++ b/drivers/gpu/drm/xe/xe_dma_buf.c @@ -145,10 +145,7 @@ static void xe_dma_buf_unmap(struct dma_buf_attachment *attach, struct sg_table *sgt, enum dma_data_direction dir) { - struct dma_buf *dma_buf = attach->dmabuf; - struct xe_bo *bo = gem_to_xe_bo(dma_buf->priv); - - if (!xe_bo_is_vram(bo)) { + if (sg_page(sgt->sgl)) { dma_unmap_sgtable(attach->dev, sgt, dir, 0); sg_free_table(sgt); kfree(sgt); -- 2.49.0

6 months, 2 weeks

4
6
0 0

Improving Linux Commit Backporting

by Manthey, Norbert

Dear Linux Stable Maintainers, while maintaining downstream Linux releases, we noticed that we have to backport some patches manually, because they are not picked up by your automated backporting. Some of these backports can be done with improved cherry-pick tooling. We have implemented a script/tool "git- fuzzy-pick" which we would like to share. Besides picking more commits, the tool also supports executing a validation script right after picking, e.g. compiling the modified source file. Picking stats and details are presented below. We would like to discuss whether you can integrate this improved tool into into your daily workflows. We already found the stable-tools repository [1] with some scripts that help automate backporting. To contribute git-fuzzy-pick there, we would need you to declare a license for the current state of this repository. To test backporting performance, we tried to backport stable-candidate patches from 6.12 to 6.1. Specifically, on tag 6.1.125 we executed the command stable show-missing-stable v6.12.12..v6.12.17 to collect patches considered for backporting. This results in 431 backport candidates. When using git-fuzzy-pick, we can pick 9 patches more than with default cherry-picking. All modifications have been validated by attempting to build the object files of the modified C source files with make using the kernels “allyesconfig” configuration. 196 Cherry-picked with --strategy=recursive --Xpatience -x 1 Applied with patch -p1 ... --fuzz=1 8 Applied with patch -p1 ... --fuzz=2 Please let us know how to best share the tool with you! Long term, we would like to integrate it into your backporting workflow, so that more kernel commits can be applied automatically. Best, Norbert [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/stable-tool…

6 months, 2 weeks

4
7
0 0

[REGRESSION] Chrome and VSCode breakage with the commit b9b588f22a0c

by Takashi Iwai

[ resent due to a wrong address for regression reporting, sorry! ] Hi, we received a bug report showing the regression on 6.13.1 kernel against 6.13.0. The symptom is that Chrome and VSCode stopped working with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker https://bugzilla.suse.com/show_bug.cgi?id=1236943 Quoting from there: """ I use the latest TW on Gnome with a 4K display and 150% scaling. Everything has been working fine, but recently both Chrome and VSCode (installed from official non-openSUSE channels) stopped working with Scaling. .... I am using VSCode with: `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. """ Surprisingly, the bisection pointed to the backport of the commit b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list to iterate simple_offset directories"). Indeed, the revert of this patch on the latest 6.13.4 was confirmed to fix the issue. Also, the reporter verified that the latest 6.14-rc release is still affected, too. For now I have no concrete idea how the patch could break the behavior of a graphical application like the above. Let us know if you need something for debugging. (Or at easiest, join to the bugzilla entry and ask there; or open another bug report at whatever you like.) BTW, I'll be traveling tomorrow, so my reply will be delayed. thanks, Takashi #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943

6 months, 2 weeks

6
29
0 0

6.1-stable fix

by Jens Axboe

Hi, Ran into an issue testing 6.1, which I discovered was introduced by a backport that was done. Here's the fix for it, please add it to the 6.1-stable mix. Thanks! -- Jens Axboe

6 months, 2 weeks

2
3
0 0

[PATCH 1/2] drm/simpledrm: Do not upcast in release helpers

by Thomas Zimmermann

The res pointer passed to simpledrm_device_release_clocks() and simpledrm_device_release_regulators() points to an instance of struct simpledrm_device. No need to upcast from struct drm_device. The upcast is harmless, as DRM device is the first field in struct simpledrm_device. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: <stable(a)vger.kernel.org> # v5.14+ --- drivers/gpu/drm/sysfb/simpledrm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sysfb/simpledrm.c b/drivers/gpu/drm/sysfb/simpledrm.c index cfb1fe07704d7..78672422bcada 100644 --- a/drivers/gpu/drm/sysfb/simpledrm.c +++ b/drivers/gpu/drm/sysfb/simpledrm.c @@ -275,7 +275,7 @@ static struct simpledrm_device *simpledrm_device_of_dev(struct drm_device *dev) static void simpledrm_device_release_clocks(void *res) { - struct simpledrm_device *sdev = simpledrm_device_of_dev(res); + struct simpledrm_device *sdev = res; unsigned int i; for (i = 0; i < sdev->clk_count; ++i) { @@ -373,7 +373,7 @@ static int simpledrm_device_init_clocks(struct simpledrm_device *sdev) static void simpledrm_device_release_regulators(void *res) { - struct simpledrm_device *sdev = simpledrm_device_of_dev(res); + struct simpledrm_device *sdev = res; unsigned int i; for (i = 0; i < sdev->regulator_count; ++i) { -- 2.49.0

6 months, 2 weeks

3
2
0 0

[PATCH v3 1/2] HID: amd_sfh: Fix SRA sensor when it's the only sensor

by Mario Limonciello

From: Mario Limonciello <mario.limonciello(a)amd.com> On systems that only have an SRA sensor connected to SFH the sensor doesn't get enabled due to a bad optimization condition of breaking the sensor walk loop. This optimization is unnecessary in the first place because if there is only one device then the loop only runs once. Drop the condition and explicitly mark sensor as enabled. Reported-by: Yijun Shen <Yijun.Shen(a)dell.com> Tested-By: Yijun Shen <Yijun_Shen(a)Dell.com> Fixes: d1c444b47100d ("HID: amd_sfh: Add support to export device operating states") Cc: stable(a)vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- v2: * Add tag --- drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c index 25f0ebfcbd5f5..c1bdf1e0d44af 100644 --- a/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c +++ b/drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c @@ -134,9 +134,6 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) for (i = 0; i < cl_data->num_hid_devices; i++) { cl_data->sensor_sts[i] = SENSOR_DISABLED; - if (cl_data->num_hid_devices == 1 && cl_data->sensor_idx[0] == SRA_IDX) - break; - if (cl_data->sensor_idx[i] == SRA_IDX) { info.sensor_idx = cl_data->sensor_idx[i]; writel(0, privdata->mmio + amd_get_p2c_val(privdata, 0)); @@ -145,8 +142,10 @@ static int amd_sfh1_1_hid_client_init(struct amd_mp2_dev *privdata) (privdata, cl_data->sensor_idx[i], ENABLE_SENSOR); cl_data->sensor_sts[i] = (status == 0) ? SENSOR_ENABLED : SENSOR_DISABLED; - if (cl_data->sensor_sts[i] == SENSOR_ENABLED) + if (cl_data->sensor_sts[i] == SENSOR_ENABLED) { + cl_data->is_any_sensor_enabled = true; privdata->dev_en.is_sra_present = true; + } continue; } -- 2.43.0

6 months, 2 weeks

1
0
0 0

[PATCH 1/1] x86/cpu/topology: Don't limit CPUs to 1 for Xen PV guests due to disabled APIC

by Petr Vaněk

Xen PV guests in DomU have APIC disabled by design, which causes topology_apply_cmdline_limits_early() to limit the number of possible CPUs to 1, regardless of the configured number of vCPUs. This is a regression introduced in version 6.9 in commit 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") which added an early check that limits CPUs if apic_is_disabled, without accounting for the fact that Xen PV guests always disable APIC even when SMP is supported. This patch fixes the issue by skipping the apic_is_disabled check for Xen PV guests, allowing them to boot with the full set of configured vCPUs. Fixes: 7c0edad3643f ("x86/cpu/topology: Rework possible CPU management") Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: x86(a)kernel.org Cc: xen-devel(a)lists.xenproject.org Cc: stable(a)vger.kernel.org # 6.9+ Signed-off-by: Petr Vaněk <arkamar(a)atlas.cz> --- arch/x86/kernel/cpu/topology.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 01456236a6dd..10aa7f471ec9 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -428,8 +428,13 @@ void __init topology_apply_cmdline_limits_early(void) { unsigned int possible = nr_cpu_ids; - /* 'maxcpus=0' 'nosmp' 'nolapic' */ - if (!setup_max_cpus || apic_is_disabled) + /* 'maxcpus=0' 'nosmp' 'nolapic' + * + * The apic_is_disabled check is ignored for Xen PV domains because Xen + * disables ACPI in unprivileged PV DomU guests, which would otherwise limit + * CPUs to 1, even if multiple vCPUs were configured. + */ + if (!setup_max_cpus || (!xen_pv_domain() && apic_is_disabled)) possible = 1; /* 'possible_cpus=N' */ -- 2.48.1

6 months, 2 weeks

2
3
0 0

[PATCH v7] KEYS: Add a list for unreferenced keys

by Jarkko Sakkinen

From: Jarkko Sakkinen <jarkko.sakkinen(a)opinsys.com> Add an isolated list of unreferenced keys to be queued for deletion, and try to pin the keys in the garbage collector before processing anything. Skip unpinnable keys. Use this list for blocking the reaping process during the teardown: 1. First off, the keys added to `keys_graveyard` are snapshotted, and the list is flushed. This the very last step in `key_put()`. 2. `key_put()` reaches zero. This will mark key as busy for the garbage collector. 3. `key_garbage_collector()` will try to increase refcount, which won't go above zero. Whenever this happens, the key will be skipped. Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)opinsys.com> --- v7: - Fixed multiple definitions (from rebasing, sorry). v6: - Rebase went wrong in v5. v5: - Rebased on top of v6.15-rc - Updated commit message to explain how spin lock and refcount isolate the time window in key_put(). v4: - Pin the key while processing key type teardown. Skip dead keys. - Revert key_gc_graveyard back key_gc_unused_keys. - Rewrote the commit message. - "unsigned long flags" declaration somehow did make to the previous patch (sorry). v3: - Using spin_lock() fails since key_put() is executed inside IRQs. Using spin_lock_irqsave() would neither work given the lock is acquired for /proc/keys. Therefore, separate the lock for graveyard and key_graveyard before reaping key_serial_tree. v2: - Rename key_gc_unused_keys as key_gc_graveyard, and re-document the function. --- include/linux/key.h | 7 ++----- security/keys/gc.c | 40 ++++++++++++++++++++++++---------------- security/keys/internal.h | 5 +++++ security/keys/key.c | 7 +++++-- 4 files changed, 36 insertions(+), 23 deletions(-) diff --git a/include/linux/key.h b/include/linux/key.h index ba05de8579ec..c50659184bdf 100644 --- a/include/linux/key.h +++ b/include/linux/key.h @@ -195,10 +195,8 @@ enum key_state { struct key { refcount_t usage; /* number of references */ key_serial_t serial; /* key serial number */ - union { - struct list_head graveyard_link; - struct rb_node serial_node; - }; + struct list_head graveyard_link; /* key->usage == 0 */ + struct rb_node serial_node; #ifdef CONFIG_KEY_NOTIFICATIONS struct watch_list *watchers; /* Entities watching this key for changes */ #endif @@ -236,7 +234,6 @@ struct key { #define KEY_FLAG_ROOT_CAN_INVAL 7 /* set if key can be invalidated by root without permission */ #define KEY_FLAG_KEEP 8 /* set if key should not be removed */ #define KEY_FLAG_UID_KEYRING 9 /* set if key is a user or user session keyring */ -#define KEY_FLAG_FINAL_PUT 10 /* set if final put has happened on key */ /* the key type and key description string * - the desc is used to match a key against search criteria diff --git a/security/keys/gc.c b/security/keys/gc.c index f27223ea4578..0a3beb68633c 100644 --- a/security/keys/gc.c +++ b/security/keys/gc.c @@ -189,6 +189,7 @@ static void key_garbage_collector(struct work_struct *work) struct rb_node *cursor; struct key *key; time64_t new_timer, limit, expiry; + unsigned long flags; kenter("[%lx,%x]", key_gc_flags, gc_state); @@ -206,21 +207,35 @@ static void key_garbage_collector(struct work_struct *work) new_timer = TIME64_MAX; + spin_lock_irqsave(&key_graveyard_lock, flags); + list_splice_init(&key_graveyard, &graveyard); + spin_unlock_irqrestore(&key_graveyard_lock, flags); + + list_for_each_entry(key, &graveyard, graveyard_link) { + spin_lock(&key_serial_lock); + kdebug("unrefd key %d", key->serial); + rb_erase(&key->serial_node, &key_serial_tree); + spin_unlock(&key_serial_lock); + } + /* As only this function is permitted to remove things from the key * serial tree, if cursor is non-NULL then it will always point to a * valid node in the tree - even if lock got dropped. */ spin_lock(&key_serial_lock); + key = NULL; cursor = rb_first(&key_serial_tree); continue_scanning: + key_put(key); while (cursor) { key = rb_entry(cursor, struct key, serial_node); cursor = rb_next(cursor); - - if (test_bit(KEY_FLAG_FINAL_PUT, &key->flags)) { - smp_mb(); /* Clobber key->user after FINAL_PUT seen. */ - goto found_unreferenced_key; + /* key_get(), unless zero: */ + if (!refcount_inc_not_zero(&key->usage)) { + key = NULL; + gc_state |= KEY_GC_REAP_AGAIN; + goto skip_dead_key; } if (unlikely(gc_state & KEY_GC_REAPING_DEAD_1)) { @@ -274,6 +289,7 @@ static void key_garbage_collector(struct work_struct *work) spin_lock(&key_serial_lock); goto continue_scanning; } + key_put(key); /* We've completed the pass. Set the timer if we need to and queue a * new cycle if necessary. We keep executing cycles until we find one @@ -286,6 +302,10 @@ static void key_garbage_collector(struct work_struct *work) key_schedule_gc(new_timer); } + spin_lock(&key_graveyard_lock); + list_splice_init(&key_graveyard, &graveyard); + spin_unlock(&key_graveyard_lock); + if (unlikely(gc_state & KEY_GC_REAPING_DEAD_2) || !list_empty(&graveyard)) { /* Make sure that all pending keyring payload destructions are @@ -328,18 +348,6 @@ static void key_garbage_collector(struct work_struct *work) kleave(" [end %x]", gc_state); return; - /* We found an unreferenced key - once we've removed it from the tree, - * we can safely drop the lock. - */ -found_unreferenced_key: - kdebug("unrefd key %d", key->serial); - rb_erase(&key->serial_node, &key_serial_tree); - spin_unlock(&key_serial_lock); - - list_add_tail(&key->graveyard_link, &graveyard); - gc_state |= KEY_GC_REAP_AGAIN; - goto maybe_resched; - /* We found a restricted keyring and need to update the restriction if * it is associated with the dead key type. */ diff --git a/security/keys/internal.h b/security/keys/internal.h index 2cffa6dc8255..4e3d9b322390 100644 --- a/security/keys/internal.h +++ b/security/keys/internal.h @@ -63,9 +63,14 @@ struct key_user { int qnbytes; /* number of bytes allocated to this user */ }; +extern struct list_head key_graveyard; +extern spinlock_t key_graveyard_lock; + extern struct rb_root key_user_tree; extern spinlock_t key_user_lock; extern struct key_user root_key_user; +extern struct list_head key_graveyard; +extern spinlock_t key_graveyard_lock; extern struct key_user *key_user_lookup(kuid_t uid); extern void key_user_put(struct key_user *user); diff --git a/security/keys/key.c b/security/keys/key.c index 7198cd2ac3a3..7511f2017b6b 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -22,6 +22,8 @@ DEFINE_SPINLOCK(key_serial_lock); struct rb_root key_user_tree; /* tree of quota records indexed by UID */ DEFINE_SPINLOCK(key_user_lock); +LIST_HEAD(key_graveyard); +DEFINE_SPINLOCK(key_graveyard_lock); unsigned int key_quota_root_maxkeys = 1000000; /* root's key count quota */ unsigned int key_quota_root_maxbytes = 25000000; /* root's key space quota */ @@ -658,8 +660,9 @@ void key_put(struct key *key) key->user->qnbytes -= key->quotalen; spin_unlock_irqrestore(&key->user->lock, flags); } - smp_mb(); /* key->user before FINAL_PUT set. */ - set_bit(KEY_FLAG_FINAL_PUT, &key->flags); + spin_lock_irqsave(&key_graveyard_lock, flags); + list_add_tail(&key->graveyard_link, &key_graveyard); + spin_unlock_irqrestore(&key_graveyard_lock, flags); schedule_work(&key_gc_work); } } -- 2.39.5

6 months, 2 weeks

2
5
0 0

[PATCH v6] staging: rtl8723bs: Add error handling for sd_read()

by Wentao Liang

The sdio_read32() calls sd_read(), but does not handle the error if sd_read() fails. This could lead to subsequent operations processing invalid data. A proper implementation can be found in sdio_readN(). Add error handling for the sd_read() to free tmpbuf and return error code if sd_read() fails. This ensure that the memcpy() is only performed when the read operation is successful. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- v6: Fix improper code to propagate error code v5: Fix error code v4: Add change log and fix error code v3: Add Cc flag v2: Change code to initialize val drivers/staging/rtl8723bs/hal/sdio_ops.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c b/drivers/staging/rtl8723bs/hal/sdio_ops.c index 21e9f1858745..eb21c7e55949 100644 --- a/drivers/staging/rtl8723bs/hal/sdio_ops.c +++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c @@ -185,7 +185,12 @@ static u32 sdio_read32(struct intf_hdl *intfhdl, u32 addr) return SDIO_ERR_VAL32; ftaddr &= ~(u16)0x3; - sd_read(intfhdl, ftaddr, 8, tmpbuf); + err = sd_read(intfhdl, ftaddr, 8, tmpbuf); + if (err) { + kfree(tmpbuf); + return (u32)err; + } + memcpy(&le_tmp, tmpbuf + shift, 4); val = le32_to_cpu(le_tmp); -- 2.42.0.windows.2

6 months, 2 weeks

3
3
0 0

[PATCH 1/2] drm/i915: Schedule the HPD poll init work on an unbound workqueue

by Imre Deak

Disabling HPD polling from i915_hpd_poll_init_work() involves probing all display connectors explicitly to account for lost hotplug interrupts. On some platforms (mostly pre-ICL) with HDMI connectors the I2C EDID bit-banging using udelay() triggers in turn the workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND warning. Fix the above by scheduling i915_hpd_poll_init_work() on a WQ_UNBOUND workqueue. It's ok to use a system WQ, since i915_hpd_poll_init_work() is properly flushed in intel_hpd_cancel_work(). The connector probing from drm_mode_config::output_poll_work resulting in the same warning is fixed by the next patch. Cc: Tejun Heo <tj(a)kernel.org> Cc: Heiner Kallweit <hkallweit1(a)gmail.com> CC: stable(a)vger.kernel.org # 6.5 Suggested-by: Tejun Heo <tj(a)kernel.org> Suggested-by: Heiner Kallweit <hkallweit1(a)gmail.com> Reported-by: Heiner Kallweit <hkallweit1(a)gmail.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9245 Link: https://lore.kernel.org/all/f7e21caa-e98d-e5b5-932a-fe12d27fde9b@gmail.com Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c b/drivers/gpu/drm/i915/display/intel_hotplug.c index e8562f6f8bb44..accc2fec562a0 100644 --- a/drivers/gpu/drm/i915/display/intel_hotplug.c +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -774,7 +774,7 @@ void intel_hpd_poll_enable(struct drm_i915_private *dev_priv) * As well, there's no issue if we race here since we always reschedule * this worker anyway */ - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } @@ -803,7 +803,7 @@ void intel_hpd_poll_disable(struct drm_i915_private *dev_priv) return; WRITE_ONCE(dev_priv->display.hotplug.poll_enabled, false); - queue_work(dev_priv->unordered_wq, + queue_work(system_unbound_wq, &dev_priv->display.hotplug.poll_init_work); } -- 2.37.2

6 months, 2 weeks

4
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025